MSYS2 build slow
Just as an intermediate result: MSYS2 make distclean tools/configure.sh stm32f4discovery/nsh time make current master real35m54,957s user2m29,879s sys 6m31,525s releases/9.0 real4m39,324s user0m28,553s sys 1m23,113s The build is much slower than it used to be. Does someone have an idea which commit could have caused this? I will start a bisect later today. (Never did before, let's see.) Johannes
RE: MSYS2 build slow
If I have done everything right with usage of git bisect, the below commit increased build time by factor 7 for MSYS2. Since this is a rather huge commit, I think I can't be helpful figuring out the actual reason. And I'm not sure if this is perhaps even considered acceptable. Regards, Johannes $ git bisect bad 7e5b0f81e93c7e879ce8434d57e8bf4e2319c1c0 is the first bad commit commit 7e5b0f81e93c7e879ce8434d57e8bf4e2319c1c0 Author: Xiang Xiao Date: Tue May 19 17:43:29 2020 +0800 build: Replace -I with INCDIR > -Original Message- > From: Schock, Johannes - NIVUS GmbH > [mailto:johannes.sch...@nivus.com] > Sent: Wednesday, May 27, 2020 10:45 AM > To: dev@nuttx.apache.org > Subject: MSYS2 build slow > > Just as an intermediate result: > MSYS2 > > make distclean > tools/configure.sh stm32f4discovery/nsh > time make > > current master > real35m54,957s > user2m29,879s > sys 6m31,525s > > releases/9.0 > real4m39,324s > user0m28,553s > sys 1m23,113s > > The build is much slower than it used to be. > Does someone have an idea which commit could have caused this? > I will start a bisect later today. (Never did before, let's see.) > > Johannes
Re: MSYS2 build slow
Hi Johannes, Did you try to reverse this commit to see if the problem goes away? BR, Alan On 5/27/20, Schock, Johannes - NIVUS GmbH wrote: > If I have done everything right with usage of git bisect, the below commit > increased build time by factor 7 for MSYS2. > Since this is a rather huge commit, I think I can't be helpful figuring out > the actual reason. > And I'm not sure if this is perhaps even considered acceptable. > > Regards, Johannes > > $ git bisect bad > 7e5b0f81e93c7e879ce8434d57e8bf4e2319c1c0 is the first bad commit > commit 7e5b0f81e93c7e879ce8434d57e8bf4e2319c1c0 > Author: Xiang Xiao > Date: Tue May 19 17:43:29 2020 +0800 > > build: Replace -I with INCDIR > >> -Original Message- >> From: Schock, Johannes - NIVUS GmbH >> [mailto:johannes.sch...@nivus.com] >> Sent: Wednesday, May 27, 2020 10:45 AM >> To: dev@nuttx.apache.org >> Subject: MSYS2 build slow >> >> Just as an intermediate result: >> MSYS2 >> >> make distclean >> tools/configure.sh stm32f4discovery/nsh >> time make >> >> current master >> real35m54,957s >> user2m29,879s >> sys 6m31,525s >> >> releases/9.0 >> real4m39,324s >> user0m28,553s >> sys 1m23,113s >> >> The build is much slower than it used to be. >> Does someone have an idea which commit could have caused this? >> I will start a bisect later today. (Never did before, let's see.) >> >> Johannes >
Re: MSYS2 build slow
it seems because ARCHINCLUDES try to figure out the search path by
invoking shell script:
diff --git a/boards/arm/stm32/stm32f4discovery/configs/cxxtest/Make.defs
b/boards/arm/stm32/stm32f4discovery/configs/cxxtest/Make.defs
index 35cdb5ab6a..f60d2d9e31 100644
--- a/boards/arm/stm32/stm32f4discovery/configs/cxxtest/Make.defs
+++ b/boards/arm/stm32/stm32f4discovery/configs/cxxtest/Make.defs
@@ -55,19 +55,16 @@ LIBSUPXX = ${shell $(CC) $(CXXFLAGS)
--print-file-name=libsupc++.a}
EXTRA_LIBPATHS = -L "${shell dirname "$(LIBSUPXX)"}"
EXTRA_LIBS = -lsupc++
+ARCHINCLUDES += ${shell $(INCDIR) -s "$(CC)" $(TOPDIR)$(DELIM)include}
+
+ARCHXXINCLUDES += ${shell $(INCDIR) -s "$(CC)" $(TOPDIR)$(DELIM)include}
+ARCHXXINCLUDES += ${shell $(INCDIR) -s "$(CC)"
$(TOPDIR)$(DELIM)include$(DELIM)cxx}
+ARCHXXINCLUDES += ${shell $(INCDIR) -s "$(CC)"
$(TOPDIR)$(DELIM)include$(DELIM)uClibc++}
+
ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
- # Windows-native toolchains
- ARCHINCLUDES = -I. -isystem "${shell cygpath -w $(TOPDIR)/include}"
- ARCHXXINCLUDES = -I. -isystem "${shell cygpath -w $(TOPDIR)/include}" \
--isystem "${shell cygpath -w $(TOPDIR)/include/cxx}" \
--isystem "${shell cygpath -w $(TOPDIR)/include/uClibc++}"
- ARCHSCRIPT = -T "${shell cygpath -w
$(TOPDIR)/boards/$(CONFIG_ARCH)/$(CONFIG_ARCH_CHIP)/$(CONFIG_ARCH_BOARD)/scripts/$(LDSCRIPT)}"
+ ARCHSCRIPT = -T "${shell cygpath -w
$(TOPDIR)$(DELIM)boards$(DELIM)$(CONFIG_ARCH)$(DELIM)$(CONFIG_ARCH_CHIP)$(DELIM)$(CONFIG_ARCH_BOARD)$(DELIM)scripts$(DELIM)$(LDSCRIPT)}"
else
- # Linux/Cygwin-native toolchain
- ARCHINCLUDES = -I. -isystem $(TOPDIR)/include
- ARCHXXINCLUDES = -I. -isystem $(TOPDIR)/include \
--isystem $(TOPDIR)/include/cxx -isystem $(TOPDIR)/include/uClibc++
- ARCHSCRIPT =
-T$(TOPDIR)/boards/$(CONFIG_ARCH)/$(CONFIG_ARCH_CHIP)/$(CONFIG_ARCH_BOARD)/scripts/$(LDSCRIPT)
+ ARCHSCRIPT =
-T$(TOPDIR)$(DELIM)boards$(DELIM)$(CONFIG_ARCH)$(DELIM)$(CONFIG_ARCH_CHIP)$(DELIM)$(CONFIG_ARCH_BOARD)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
endif
ARCHXXINCLUDES is a deferred variable which mean the script will
exeutable in every reference. Could you try this:
ARCHXXINCLUDES := ${shell $(INCDIR) -s "$(CC)" $(TOPDIR)$(DELIM)include}
ARCHXXINCLUDES += ${shell $(INCDIR) -s "$(CC)"
$(TOPDIR)$(DELIM)include$(DELIM)cxx}
ARCHXXINCLUDES += ${shell $(INCDIR) -s "$(CC)"
$(TOPDIR)$(DELIM)include$(DELIM)uClibc++}
https://www.gnu.org/software/make/manual/html_node/Reading-Makefiles.html
On Wed, May 27, 2020 at 9:26 PM Schock, Johannes - NIVUS GmbH
wrote:
>
> If I have done everything right with usage of git bisect, the below commit
> increased build time by factor 7 for MSYS2.
> Since this is a rather huge commit, I think I can't be helpful figuring out
> the actual reason.
> And I'm not sure if this is perhaps even considered acceptable.
>
> Regards, Johannes
>
> $ git bisect bad
> 7e5b0f81e93c7e879ce8434d57e8bf4e2319c1c0 is the first bad commit
> commit 7e5b0f81e93c7e879ce8434d57e8bf4e2319c1c0
> Author: Xiang Xiao
> Date: Tue May 19 17:43:29 2020 +0800
>
> build: Replace -I with INCDIR
>
> > -Original Message-
> > From: Schock, Johannes - NIVUS GmbH
> > [mailto:johannes.sch...@nivus.com]
> > Sent: Wednesday, May 27, 2020 10:45 AM
> > To: dev@nuttx.apache.org
> > Subject: MSYS2 build slow
> >
> > Just as an intermediate result:
> > MSYS2
> >
> > make distclean
> > tools/configure.sh stm32f4discovery/nsh
> > time make
> >
> > current master
> > real35m54,957s
> > user2m29,879s
> > sys 6m31,525s
> >
> > releases/9.0
> > real4m39,324s
> > user0m28,553s
> > sys 1m23,113s
> >
> > The build is much slower than it used to be.
> > Does someone have an idea which commit could have caused this?
> > I will start a bisect later today. (Never did before, let's see.)
> >
> > Johannes
Re: The new Apache NuttX Logo
The new logo could be viewed online here: https://cwiki.apache.org/confluence/display/NUTTX/New+Apache+Nuttx+Logo Please give your feedback and suggestoion. Are there any updates on the proposed new NuttX logos? We stopped discussing this with no follow through plan. I suppose that with no additional action, the default position is that we do not change logos. I think that what is missing in the current logos is a message. What is it that we want to convey with a new logo. Without a message, it is arbitrary artwork and there is nothing to motivate a selection. Perhaps we need some marketing folks involved as well as graphic designers?
Re: The new Apache NuttX Logo
On Wed, May 27, 2020 at 10:45 AM Gregory Nutt wrote: > > The new logo could be viewed online here: > > https://cwiki.apache.org/confluence/display/NUTTX/New+Apache+Nuttx+Logo > > Please give your feedback and suggestoion. > > Are there any updates on the proposed new NuttX logos? We stopped > discussing this with no follow through plan. > > I suppose that with no additional action, the default position is that > we do not change logos. > > I think that what is missing in the current logos is a message. What is > it that we want to convey with a new logo. Without a message, it is > arbitrary artwork and there is nothing to motivate a selection. Perhaps > we need some marketing folks involved as well as graphic designers? Forgive me if this was done and I missed it, but... I think we should have some kind of NuttX new logo "contest" (no actual prize for winning, except that the winner gets a warm fuzzy feeling inside, and the project adopts their logo). The contest should be open for some predefined length of time, allowing people enough time to think and experiment with logo concepts. Once the deadline arrives, we as a community would vote for the best logo out of all the entries. If we go this route, then as a community we need to make up an announcement, which would then be posted to all NuttX channels (e.g., here on dev@, at the LinkedIn group, etc) to maximize the number of participants. The point is that it should be open to everyone to contribute a logo for consideration. Nathan
Re: The new Apache NuttX Logo
I want to ask a question based on the draft proposals. Are we allowed to think broader? :) For instance, I wonder what the community would think about using a mascot. Erdem Gregory Nutt , 27 May 2020 Çar, 16:45 tarihinde şunu yazdı: > > > The new logo could be viewed online here: > > https://cwiki.apache.org/confluence/display/NUTTX/New+Apache+Nuttx+Logo > > Please give your feedback and suggestoion. > > Are there any updates on the proposed new NuttX logos? We stopped > discussing this with no follow through plan. > > I suppose that with no additional action, the default position is that > we do not change logos. > > I think that what is missing in the current logos is a message. What is > it that we want to convey with a new logo. Without a message, it is > arbitrary artwork and there is nothing to motivate a selection. Perhaps > we need some marketing folks involved as well as graphic designers? > >
Re: The new Apache NuttX Logo
On 5/27/2020 8:53 AM, Nathan Hartman wrote: On Wed, May 27, 2020 at 10:45 AM Gregory Nutt wrote: The new logo could be viewed online here: https://cwiki.apache.org/confluence/display/NUTTX/New+Apache+Nuttx+Logo Please give your feedback and suggestoion. Are there any updates on the proposed new NuttX logos? We stopped discussing this with no follow through plan. I suppose that with no additional action, the default position is that we do not change logos. I think that what is missing in the current logos is a message. What is it that we want to convey with a new logo. Without a message, it is arbitrary artwork and there is nothing to motivate a selection. Perhaps we need some marketing folks involved as well as graphic designers? Forgive me if this was done and I missed it, but... I think we should have some kind of NuttX new logo "contest" (no actual prize for winning, except that the winner gets a warm fuzzy feeling inside, and the project adopts their logo). The contest should be open for some predefined length of time, allowing people enough time to think and experiment with logo concepts. Once the deadline arrives, we as a community would vote for the best logo out of all the entries. If we go this route, then as a community we need to make up an announcement, which would then be posted to all NuttX channels (e.g., here on dev@, at the LinkedIn group, etc) to maximize the number of participants. The point is that it should be open to everyone to contribute a logo for consideration. Nathan A contest is fine, maybe we could even create a pool to purchase a prize... like a nice, high end NuttX board? I would contribute. But if we want to make progress, we should from a committee of some kind that will take the responsibility. Nothing ever happens if we delegate things to that non-identified, nameless person.
Re: The new Apache NuttX Logo
I want to ask a question based on the draft proposals. Are we allowed to think broader? :) For instance, I wonder what the community would think about using a mascot. I am open to that idea myself.. like Linux' penguin? Such a mascot would need to have wide appeal and acceptance, I think a higher level of acceptance than a simple logo change. After all, such a mascot would have to represent how we feel as a project. That might be hard to accomplish here. People here are very diverse. I, for one, am open to all sorts of creative ideas. For example, I always like Zephyr's kite logo. What does a kite have to do with the RTOS? Nothing, but it conveys a certain feeling about how they feel about the RTOS. I think it would be nice to have a graphic or a mascot that conveys how we feel about this RTOS as well.
Re: The new Apache NuttX Logo
In my opinion there should be a poll (on the same page) so that people can vote the one that they like Thanks Alin On Sat, Apr 18, 2020 at 9:47 AM Alan Carvalho de Assis wrote: > Good point David! > > I got all logos from PDF and put it publicly visible: > > https://cwiki.apache.org/confluence/display/NUTTX/New+Apache+Nuttx+Logo > > None of those logo respect the original N and X and lowercase utt of NuttX. > > I think Mr. Greg never enforced it too much, although he almost always > wrote NuttX. > > I recall Mr. Wolfgang Denx in the U-Boot mailing list always to scold > on people who misspelling it as uboot, u-boot, uBoot, etc. > > So I always called "NuttX as NuttX" and as you can see even in the URL > of NuttX Channel it is present: > > https://www.youtube.com/c/NuttXChannel > > BR, > > Alan > > On 4/14/20, David Alessio wrote: > > I don’t wish to offend anyone but I object to all options on the basis > that > > “NuttX” should be spelled with capital ‘N’ and ‘X’, lowercase “utt”. > > > > Regards, > > -david > > > > Sent from my iPhone > > > >> On Apr 13, 2020, at 7:42 PM, Xiang Xiao > >> wrote: > >> > >> The new logo could be viewed online here: > >> https://cwiki.apache.org/confluence/display/NUTTX/New+Apache+Nuttx+Logo > >> Please give your feedback and suggestoion. > >> > >> Thanks > >> > >> Xiang > >> > >>> On Tue, Apr 14, 2020 at 5:54 AM Justin Mclean < > jus...@classsoftware.com> > >>> wrote: > >>> > >>> Hi, > >>> > >>> It would be easy to put the image on your wiki / confluence. > >>> > >>> Justin > > >
Re: The new Apache NuttX Logo
On Wed, May 27, 2020 at 11:45 AM Gregory Nutt wrote: > A contest is fine, maybe we could even create a pool to purchase a > prize... like a nice, high end NuttX board? I would contribute. That would provide more incentive to participate. Let's find out if we can do this. Mentors? Is it allowed? Is there a process we have to follow? I wonder if a board is the best prize. It might not be helpful to someone who is a great logo artist but not necessarily an embedded developer. > But if we want to make progress, we should from a committee of some kind > that will take the responsibility. Nothing ever happens if we delegate > things to that non-identified, nameless person. There is the PPMC. Do we need a different committee? Perhaps a subset of the PPMC, or a subset + some other interested community members? Participating in new logo creation could be a good step for someone who wants to join the PPMC to earn the merit? Nathan
Kernel Threads with Custom Stacks
I tried to summarize the discussion of PR 1099 in a Wiki page. The PR comments got messy and unreadable, here is a cleaned up version: https://cwiki.apache.org/confluence/display/NUTTX/Kernel+Threads+with+Custom+Stacks
Re: The new Apache NuttX Logo
A contest is fine, maybe we could even create a pool to purchase a prize... like a nice, high end NuttX board? I would contribute. That would provide more incentive to participate. Let's find out if we can do this. Mentors? Is it allowed? Is there a process we have to follow? I wonder if a board is the best prize. It might not be helpful to someone who is a great logo artist but not necessarily an embedded developer. Well, it could be a gift certificate of some kind. Seems like it must be embedded RTOS themed in some way, however. Or maybe a trophy? But if we want to make progress, we should from a committee of some kind that will take the responsibility. Nothing ever happens if we delegate things to that non-identified, nameless person. There is the PPMC. Do we need a different committee? Perhaps a subset of the PPMC, or a subset + some other interested community members? Participating in new logo creation could be a good step for someone who wants to join the PPMC to earn the merit? The PPMC is notoriously bad for taking responsibility and following through. It is an anarchy, after all. But a small focused, involved team given license to do the job would probably work better than cast of dozens with no particular interest or sense that they have the responsibility or authority to do anything.
Re: MSYS2 build slow
it seems because ARCHINCLUDES try to figure out the search path by invoking shell script: But wouldn't that affect all platforms proportionally? Why would that cause such a huge increase on MSYS2. I saw a 7 minute build time on Cygwin. That is also very high, but not at all the kind of time increase that Johannes is seeing. I was building on Cygwin at about 3 minutes at some time in the past, so the build time has increases significantly for me too. On Cygwin, I have always noticed that the build rate would slow down when it got the to the drivers/ directory. It would slow by a factor of 2-3X. This, we disccovered, as do to all of the include paths that had to be searched. When you build the drivrs/, there can be many include paths that really slows down the build. Could something like that be happening here too?
Re: MSYS2 build slow
it seems because ARCHINCLUDES try to figure out the search path by invoking shell script: But wouldn't that affect all platforms proportionally? Why would that cause such a huge increase on MSYS2. I saw a 7 minute build time on Cygwin. That is also very high, but not at all the kind of time increase that Johannes is seeing. I was building on Cygwin at about 3 minutes at some time in the past, so the build time has increases significantly for me too. On Cygwin, I have always noticed that the build rate would slow down when it got the to the drivers/ directory. It would slow by a factor of 2-3X. This, we disccovered, as do to all of the include paths that had to be searched. When you build the drivrs/, there can be many include paths that really slows down the build. Could something like that be happening here too? I have seen a slow-down in builds under Linux as well. But since the Linux builds are already so fast it is less evident. Before i was building at around 20-30 seconds per build; now it is are 45-60 seconds per build. Has anyone else seen this?
Re: MSYS2 build slow
it seems because ARCHINCLUDES try to figure out the search path by invoking shell script: But wouldn't that affect all platforms proportionally? Why would that cause such a huge increase on MSYS2. I saw a 7 minute build time on Cygwin. That is also very high, but not at all the kind of time increase that Johannes is seeing. I was building on Cygwin at about 3 minutes at some time in the past, so the build time has increases significantly for me too. On Cygwin, I have always noticed that the build rate would slow down when it got the to the drivers/ directory. It would slow by a factor of 2-3X. This, we disccovered, as do to all of the include paths that had to be searched. When you build the drivrs/, there can be many include paths that really slows down the build. Could something like that be happening here too? I have seen a slow-down in builds under Linux as well. But since the Linux builds are already so fast it is less evident. Before i was building at around 20-30 seconds per build; now it is are 45-60 seconds per build. Has anyone else seen this? I should clarify... that is using testbuild.sh so it includes make disclean and configure.sh times too. The actual build time is somewhat less than that.
Re: The new Apache NuttX Logo
Well, it could be a gift certificate of some kind. Seems like it must be embedded RTOS themed in some way, however. Or maybe a trophy? Better... a T-shirt or hoody with the selected logo on it.
Re: The new Apache NuttX Logo
On Wed, May 27, 2020 at 5:15 PM Gregory Nutt wrote: > > > Well, it could be a gift certificate of some kind. Seems like it must > > be embedded RTOS themed in some way, however. > > > > Or maybe a trophy? > > Better... a T-shirt or hoody with the selected logo on it. That's a neat idea! Nathan
Re: MSYS2 build slow
On Wed, May 27, 2020 at 3:39 PM Gregory Nutt wrote: > > >> it seems because ARCHINCLUDES try to figure out the search path by > >> invoking shell script: > > > > But wouldn't that affect all platforms proportionally? Why would that > > cause such a huge increase on MSYS2. > > > > I saw a 7 minute build time on Cygwin. That is also very high, but > > not at all the kind of time increase that Johannes is seeing. I was > > building on Cygwin at about 3 minutes at some time in the past, so the > > build time has increases significantly for me too. > > > > On Cygwin, I have always noticed that the build rate would slow down > > when it got the to the drivers/ directory. It would slow by a factor > > of 2-3X. This, we disccovered, as do to all of the include paths that > > had to be searched. When you build the drivrs/, there can be many > > include paths that really slows down the build. > > > > Could something like that be happening here too? > > I have seen a slow-down in builds under Linux as well. But since the > Linux builds are already so fast it is less evident. Before i was > building at around 20-30 seconds per build; now it is are 45-60 seconds > per build. > > Has anyone else seen this? I build on Linux and those build times seem fast to me (20-30 seconds, 45-60 seconds). I don't know if I've ever had builds that fast, but it might be my configurations, or my machine. I'll build one now... Latest master: 1m 47s Let me get an older revision... 1m 50s to build with bb10e0fc25a1c6006e8ad2724be29173d4858494 which is before the commit mentioned by the OP. These build times are pretty consistent with what they've always been for me, approximately 2 minutes for a complete build. So, at least so far, I don't see a change... Nathan
Re: MSYS2 build slow
Okay, so only MSYS2 is seeing a dramatic change. That is a mystery. On 5/27/2020 6:06 PM, Nathan Hartman wrote: On Wed, May 27, 2020 at 3:39 PM Gregory Nutt wrote: it seems because ARCHINCLUDES try to figure out the search path by invoking shell script: But wouldn't that affect all platforms proportionally? Why would that cause such a huge increase on MSYS2. I saw a 7 minute build time on Cygwin. That is also very high, but not at all the kind of time increase that Johannes is seeing. I was building on Cygwin at about 3 minutes at some time in the past, so the build time has increases significantly for me too. On Cygwin, I have always noticed that the build rate would slow down when it got the to the drivers/ directory. It would slow by a factor of 2-3X. This, we disccovered, as do to all of the include paths that had to be searched. When you build the drivrs/, there can be many include paths that really slows down the build. Could something like that be happening here too? I have seen a slow-down in builds under Linux as well. But since the Linux builds are already so fast it is less evident. Before i was building at around 20-30 seconds per build; now it is are 45-60 seconds per build. Has anyone else seen this? I build on Linux and those build times seem fast to me (20-30 seconds, 45-60 seconds). I don't know if I've ever had builds that fast, but it might be my configurations, or my machine. I'll build one now... Latest master: 1m 47s Let me get an older revision... 1m 50s to build with bb10e0fc25a1c6006e8ad2724be29173d4858494 which is before the commit mentioned by the OP. These build times are pretty consistent with what they've always been for me, approximately 2 minutes for a complete build. So, at least so far, I don't see a change... Nathan
Re: The new Apache NuttX Logo
Before it's too late, I'd like to pose the question: Is there no-one who prefers NuttX be spelled with lower-case "utt"? Respectfully, -david On Wed, May 27, 2020 at 3:01 PM Nathan Hartman wrote: > On Wed, May 27, 2020 at 5:15 PM Gregory Nutt wrote: > > > > > > Well, it could be a gift certificate of some kind. Seems like it must > > > be embedded RTOS themed in some way, however. > > > > > > Or maybe a trophy? > > > > Better... a T-shirt or hoody with the selected logo on it. > > > That's a neat idea! > > Nathan >
