On Sun, May 31, 2020 at 12:41 PM Nathan Hartman
wrote:
> FWIW the build has become noticeably faster for me with latest master:
> 1m21s now. Before, the build consistently took about 1m50s. So that's
> 30 seconds saved. I build on Linux.
I just wanted to follow up on this and say that apparently
Sorry for being so unresponsive, we had bank holidays and I've been away from
my computer for 3 days.
> -Original Message-
> From: Gregory Nutt [mailto:spudan...@gmail.com]
> Not if CONFIG_HOST_WINDOWS=y in the defconfig file. That is what is set
> in stm32f4discovery:nsh:
>
> $ grep -r
31/20 10:46 AM (GMT-06:00) To:
dev@nuttx.apache.org Subject: Re: MSYS2 build slow On Sun, May 31, 2020 at
12:44 PM Gregory Nutt wrote:>> > FWIW the build has
become noticeably faster for me with latest master:> > 1m21s now. Before, the
build consistently took about 1m50s. So
On Sun, May 31, 2020 at 12:44 PM Gregory Nutt wrote:
>
> > FWIW the build has become noticeably faster for me with latest master:
> > 1m21s now. Before, the build consistently took about 1m50s. So that's
> > 30 seconds saved. I build on Linux.
> yes I have seen improvements of 25-30% on all platf
FWIW the build has become noticeably faster for me with latest master:
1m21s now. Before, the build consistently took about 1m50s. So that's
30 seconds saved. I build on Linux.
yes I have seen improvements of 25-30% on all platforms, and more on
some Window's platforms that are more sensitive
On Wed, May 27, 2020 at 8:06 PM Nathan Hartman wrote:
> 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
FW
There is no issue in reporting complaints here. :)
The changes to Make.defs do also improve performance, however we need
to do some hacks to get rid of the error messages.
On Sun, May 31, 2020 at 1:16 PM Maciej Wójcik wrote:
Thanks for explanation. I went through that PR right now.
I was j
There is no issue in reporting complaints here. :)
The changes to Make.defs do also improve performance, however we need
to do some hacks to get rid of the error messages.
On Sun, May 31, 2020 at 1:16 PM Maciej Wójcik wrote:
>
> Thanks for explanation. I went through that PR right now.
>
> I was
Thanks for explanation. I went through that PR right now.
I was just reporting as a good citizen :) I will check Issue pane next time
before spamming.
Note that the error messages do not come from incorporating incdir.c
into the build system but rather from using immediate variables in
Make.defs
On Sun, May 31, 2020 at 1:47 PM Abdelatif Guettouche
wrote:
>
> > When I simply clone
> > and configure NuttX, I get a repeated error.
>
> Yes, we are
> When I simply clone
> and configure NuttX, I get a repeated error.
Yes, we are aware of those and actually have a solution (in
https://github.com/apache/incubator-nuttx/pull/1152)
However, we are still discussing other alternatives (or even reverting
the changes)
Sorry for the inconvenience.
O
>
> PR 1149 has been merged. That means that the incdir.c program has now
> been incorporated into the build system.
There might be some regression within this solution. When I simply clone
and configure NuttX, I get a repeated error. It might be related to recent
change
mkdir test
cd test
git
Without specifying -g CONFIG_HOST_LINUX is assumed.
This worked well in the past with MSYS2.
But I will try -g later today.
Not if CONFIG_HOST_WINDOWS=y in the defconfig file. That is what is set
in stm32f4discovery:nsh:
$ grep -r CONFIG_HOST
boards/arm/stm32/stm32f4discovery/configs/nsh/
Without specifying -g CONFIG_HOST_LINUX is assumed.
This worked well in the past with MSYS2.
But I will try -g later today.
Johannes
> -Original Message-
> From: Gregory Nutt [mailto:spudan...@gmail.com]
> > For MSYS2 on my i7-3770 it's (every tests with jobs enabled):
> > # make distclea
For MSYS2 on my i7-3770 it's (every tests with jobs enabled):
# make distclean
# tools/configure.sh stm32f4discovery/nsh
You really should specific -g on the configure.sh command line.
Otherwise, the system will assume you are building for Cygwin. There are
only a few differences between Cygw
am I the only
MSYS2 user?).
Overall it's still slower than before, but it's back in the ballpark.
Thanks.
Johannes
> -Original Message-
> From: Gregory Nutt [mailto:spudan...@gmail.com]
> Sent: Saturday, May 30, 2020 4:25 AM
> To: dev@nuttx.apache.org
> Subject: Re
Johannes,
PR 1149 has been merged. That means that the incdir.c program has now
been incorporated into the build system. It all checks out: I have
pretty thoroughly verified it on Cygwin and Abdelatif and Alan Carvalho
de Assis have checked it out well on Linux. The PR also passes all of
As a comparison I did:
- make clean
- make
The dependencies only have to be recreated on the first build, not on
subsequent builds. In that case I get 3 minutes and 30 seconds. So
the Cygwin dependency generation vi mkwindeps.sh requires about 2
minutes by itself
But with the c
I am most of the way through converting incdir.sh to a C version,
incdir.c. I will probably submit a PR that just adds the .c file
(without changing the build system). Then we can experiment with it
and make sure we are comfortable before bringing it into the build.
I will first test with
I must admit I thought about that idea also, but I wasn't sure about
the portability issue.
You could also think about a autogenerated Make.defs during configure
with then hard coded include paths which should be the fastest
possibility.
Since Make.defs is already copied, perhaps it could
I must admit I thought about that idea also, but I wasn't sure about the
portability issue.
You could also think about a autogenerated Make.defs during configure with then
hard coded include paths which should be the fastest possibility.
Since Make.defs is already copied, perhaps it could al
> From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
> Could you try the method I said before? Immediate make variable could
> avoid invoke the shell script at every reference location which is some form
> of cache inside make instead of incdir.sh.
It's
real22m50,526s
user1m37,024s
sys
Isn't there a possibility to cache the results of the system checks
inside incdir.sh?
The cost of getting 'os' is fork + new shell + uname
The cost of gcc is fork + new shell + grep
The cost of exfile if for + new shell + basename
Yes, so that does have to fork a lot of additional shell ins
By hardcoding
os=Msys
gcc=arm-none-eabi-gcc
exefile=arm-none-eabi-gcc
inside incdir.sh
time tools/incdir.sh -s
arm-none-eabi-gcc/home/Schock/nuttx/nuttx/include
reduced from 180ms to 40ms.
Overall, this reduced build time from 30min to an acceptable 6min.
So incdir.sh is taking too much t
By hardcoding
os=Msys
gcc=arm-none-eabi-gcc
exefile=arm-none-eabi-gcc
inside incdir.sh
time tools/incdir.sh -s
arm-none-eabi-gcc/home/Schock/nuttx/nuttx/include
reduced from 180ms to 40ms.
Overall, this reduced build time from 30min to an acceptable 6min.
So incdir.sh is taking too much tim
By hardcoding
os=Msys
gcc=arm-none-eabi-gcc
exefile=arm-none-eabi-gcc
inside incdir.sh
time tools/incdir.sh -s arm-none-eabi-gcc/home/Schock/nuttx/nuttx/include
reduced from 180ms to 40ms.
Overall, this reduced build time from 30min to an acceptable 6min.
So incdir.sh is taking too much time i
shell script at every reference location which is some form of cache
inside make instead of incdir.sh.
> -Original Message-
> From: Gregory Nutt
> Sent: Friday, May 29, 2020 10:11 PM
> To: dev@nuttx.apache.org
> Subject: Re: MSYS2 build slow
>
>
> > Would please
Would please someone do the following command on Linux and Cygwin?
time tools/incdir.sh -s arm-none-eabi-gcc /home/Schock/nuttx/nuttx/include
(Replace the path with your NuttX path.)
For MSYS2 it's in the range of:
real0m0,189s
user0m0,061s
sys 0m0,045s
I don't have the Linux bo
he.org
> Subject: RE: MSYS2 build slow
>
> Would please someone do the following command on Linux and Cygwin?
>
> time tools/incdir.sh -s arm-none-eabi-gcc
> /home/Schock/nuttx/nuttx/include
>
> (Replace the path with your NuttX path.)
>
> For MSYS2 it's in the r
For me it looks as below (in windows, cygwin environment).
$ time tools/incdir.sh -s arm-none-eabi-gcc ./include
-isystem "./include"
real0m0.342s
user0m0.046s
sys 0m0.261s
With best regards,
Phani.
On Fri, May 29, 2020 at 6:43 PM Schock, Johannes - NIVUS GmbH <
johannes.sch...@nivu
Would please someone do the following command on Linux and Cygwin?
time tools/incdir.sh -s arm-none-eabi-gcc /home/Schock/nuttx/nuttx/include
(Replace the path with your NuttX path.)
For MSYS2 it's in the range of:
real0m0,189s
user0m0,061s
sys 0m0,045s
Thanks, Johannes
> From: Gr
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
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 minut
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 o
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
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
it 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: We
t;
> 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
>
nes - 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 mak
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 someo
40 matches
Mail list logo
