You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Sebastien Lorquet <se...@lorquet.fr> on 2023/03/07 08:18:34 UTC
Build system is broken
Hi,
This morning I updated my working copy, ran git pull origin master and
rebuilt my OS
Now when I run make I get no output. But the cpu fan works.
Only the last line of the console shows text, there is no log makefile
anymore.
This is AWFUL!
What happened?
Was make updated by linux mint?
Were makefiles in nuttx updated in such a profound way?
I frankly dont understand.
Sebastien
Re: Build system is broken
Posted by Sebastien Lorquet <se...@lorquet.fr>.
*yet again* it is the proof that multiplying the channels of
communication just dilutes them.
Anything considered a breaking change requiring the use of explicit doc
in the next release SHOULD be discussed here openly.
The commit was approved by David, OK, and, again, xiaomi.
This is not exactly several members.
I read that the last comment was "Thanks for your suggestion! I will try
to enhance the compatibility in different shell environment." but it has
still be committed.
Sebastien
On 3/7/23 14:22, Alin.Jerpelea@sony.com wrote:
> Hi Sebastien,
>
> The commit 03b164f59ce40a3f5677b0588af2aee8d9697bf6 tools/makefile: silent all compile output
>
> It has been reviewed and approved by several members
> https://github.com/apache/nuttx/pull/8378
>
> Best regards
> Alin
>
>
> -----Original Message-----
> From: Sebastien Lorquet <se...@lorquet.fr>
> Sent: den 7 mars 2023 14:12
> To: dev@nuttx.apache.org
> Subject: Re: Build system is broken
>
> Hi,
>
> Do your realize how counter-intuitive this is?
>
> I would have NEVER imagined that V=0 is not the exact contrary of V=1!
>
> Can this silent mode be made optional in a config setting please? It is really a non-feature. it's just a fantasy to please some committer, and should have never been accepted imho.
>
>
> When I want to contribute a one liner to submit a new flash chip I get forced to wait 48 hours for useless automatic tests that will not even compile my new code, and such profound changes gets integrated immediately with almost no review other than an automatic build. I know it because some commits do not have corresponding pull requests.
>
> This gives a feeling of double standard that does not seem in line with the inviolables of this project.
>
>
> Tomek: Thanks, but I am not interested in workarounds that look like
> "here is a way to avoid asking why a change was made".
>
>
> Sebastien
>
> On 3/7/23 13:45, Nathan Hartman wrote:
>> On Tue, Mar 7, 2023 at 7:23 AM Tomek CEDRO <to...@cedro.info> wrote:
>>
>>> On Tue, Mar 7, 2023 at 9:24 AM Sebastien Lorquet wrote:
>>>> No
>>>> V=1 is an entirely different thing.
>>>> I dont want to see the output mangled with tons of arm-none-eabi-gcc
>>>> command lines.
>>>> This stuff is another breakage
>>>> Sebastien
>>
>> There is V=0 which gives the same output as before.
>>
>> It needs to be documented somehow, and in a way that people will see it, or
>> we will get a lot of complaints and questions about it after the next
>> release.
>>
>> Nathan
>>
RE: Build system is broken
Posted by "Alin.Jerpelea@sony.com" <Al...@sony.com>.
Hi Sebastien,
The commit 03b164f59ce40a3f5677b0588af2aee8d9697bf6 tools/makefile: silent all compile output
It has been reviewed and approved by several members
https://github.com/apache/nuttx/pull/8378
Best regards
Alin
-----Original Message-----
From: Sebastien Lorquet <se...@lorquet.fr>
Sent: den 7 mars 2023 14:12
To: dev@nuttx.apache.org
Subject: Re: Build system is broken
Hi,
Do your realize how counter-intuitive this is?
I would have NEVER imagined that V=0 is not the exact contrary of V=1!
Can this silent mode be made optional in a config setting please? It is really a non-feature. it's just a fantasy to please some committer, and should have never been accepted imho.
When I want to contribute a one liner to submit a new flash chip I get forced to wait 48 hours for useless automatic tests that will not even compile my new code, and such profound changes gets integrated immediately with almost no review other than an automatic build. I know it because some commits do not have corresponding pull requests.
This gives a feeling of double standard that does not seem in line with the inviolables of this project.
Tomek: Thanks, but I am not interested in workarounds that look like
"here is a way to avoid asking why a change was made".
Sebastien
On 3/7/23 13:45, Nathan Hartman wrote:
> On Tue, Mar 7, 2023 at 7:23 AM Tomek CEDRO <to...@cedro.info> wrote:
>
>> On Tue, Mar 7, 2023 at 9:24 AM Sebastien Lorquet wrote:
>>> No
>>> V=1 is an entirely different thing.
>>> I dont want to see the output mangled with tons of arm-none-eabi-gcc
>>> command lines.
>>> This stuff is another breakage
>>> Sebastien
>
>
> There is V=0 which gives the same output as before.
>
> It needs to be documented somehow, and in a way that people will see it, or
> we will get a lot of complaints and questions about it after the next
> release.
>
> Nathan
>
Re: Build system is broken
Posted by Petro Karashchenko <pe...@gmail.com>.
Hi,
I agree with Nathan. The "V=0" -- seems to be an explicit option for "no
verbose" compilation (in other worlds should suppress all the outputs
except errors I hope).
Best regards,
Petro
вт, 7 бер. 2023 р. о 15:59 Nathan Hartman <ha...@gmail.com> пише:
> On Tue, Mar 7, 2023 at 8:12 AM Sebastien Lorquet <se...@lorquet.fr>
> wrote:
>
> > Hi,
> >
> > Do your realize how counter-intuitive this is?
> >
> > I would have NEVER imagined that V=0 is not the exact contrary of V=1!
>
>
>
> I agree. I think it should be:
> * No V argument: Make behaves as originally
> * V=0: Make's current behavior with output on one line
> * V=1: Verbose, as in many other projects' makefiles
>
> In other words the current behavior on master it should be opt-in, not
> opt-out.
>
> Perhaps others have reasons why that should not be so. I hope they would
> respond and explain their rationale.
>
> Nathan
>
Re: Build system is broken
Posted by Nathan Hartman <ha...@gmail.com>.
On Tue, Mar 7, 2023 at 8:12 AM Sebastien Lorquet <se...@lorquet.fr>
wrote:
> Hi,
>
> Do your realize how counter-intuitive this is?
>
> I would have NEVER imagined that V=0 is not the exact contrary of V=1!
I agree. I think it should be:
* No V argument: Make behaves as originally
* V=0: Make's current behavior with output on one line
* V=1: Verbose, as in many other projects' makefiles
In other words the current behavior on master it should be opt-in, not
opt-out.
Perhaps others have reasons why that should not be so. I hope they would
respond and explain their rationale.
Nathan
Re: Build system is broken
Posted by Gregory Nutt <sp...@gmail.com>.
Agreed!
The dev list is the only official way to communicate with all users of
NuttX. I would think ALL important discussions need to occur there.
Github is for developers; dev is for everyone.
On 3/7/2023 11:43 AM, Nathan Hartman wrote:
> On Tue, Mar 7, 2023 at 12:27 PM Alan C. Assis <ac...@gmail.com> wrote:
>
>> Some important things to keep in mind to avoid these kind of frustration:
>>
>> 1) NuttX development is on GitHub, although this mailing list has dev@ in
>> its name, the development is not here. In the past Greg used to accept
>> patches over mailing list. But now NuttX is an Apache project TLP;
>
>
> I would like to say that usually (and historically) Apache project
> discussion *are* supposed to be on list (on the mailing list).
>
> Some projects, like NuttX is doing, have moved to a GitHub centric way of
> working.
>
> There have been some discussions on the foundation's members only list
> about whether this is desired, because there is significance to having
> discussions archived on ASF hardware, which GitHub PRs are not. ASF cannot
> ensure the longevity of discussions hosted on 3rd party sites.
>
> So far those members discussions have not turned up anything conclusive.
>
> I think there is significance to having technical discussions on list.
> GitHub is convenient for reviewing individual lines of code and I'm okay
> with that. But I think that bigger and more significant things that affect
> everyone should be discussed on list, preferably before working hard on a
> PR. This way the community can decide the best technical direction before
> too much time is invested writing code.
>
> Cheers
> Nathan
>
Re: Build system is broken
Posted by Nathan Hartman <ha...@gmail.com>.
On Tue, Mar 7, 2023 at 12:27 PM Alan C. Assis <ac...@gmail.com> wrote:
> Some important things to keep in mind to avoid these kind of frustration:
>
> 1) NuttX development is on GitHub, although this mailing list has dev@ in
> its name, the development is not here. In the past Greg used to accept
> patches over mailing list. But now NuttX is an Apache project TLP;
I would like to say that usually (and historically) Apache project
discussion *are* supposed to be on list (on the mailing list).
Some projects, like NuttX is doing, have moved to a GitHub centric way of
working.
There have been some discussions on the foundation's members only list
about whether this is desired, because there is significance to having
discussions archived on ASF hardware, which GitHub PRs are not. ASF cannot
ensure the longevity of discussions hosted on 3rd party sites.
So far those members discussions have not turned up anything conclusive.
I think there is significance to having technical discussions on list.
GitHub is convenient for reviewing individual lines of code and I'm okay
with that. But I think that bigger and more significant things that affect
everyone should be discussed on list, preferably before working hard on a
PR. This way the community can decide the best technical direction before
too much time is invested writing code.
Cheers
Nathan
Re: Build system is broken
Posted by "Alan C. Assis" <ac...@gmail.com>.
Some important things to keep in mind to avoid these kind of frustration:
1) NuttX development is on GitHub, although this mailing list has dev@ in
its name, the development is not here. In the past Greg used to accept
patches over mailing list. But now NuttX is an Apache project TLP;
2) You cannot be absent of GitHub development and later complain that
modification X or Y don't pleasure you. It is not fear with those that are
actively working hard, day by day.
So, the best way to avoid it is reserve just 15min of your precious time to
take a look at GitHub each day.
BR,
Alan
On Tuesday, March 7, 2023, Sebastien Lorquet <se...@lorquet.fr> wrote:
> Greg,
>
> Thanks. The commit link is there:
>
> https://github.com/apache/nuttx/commit/e6227e19433c4999d5004
> 37d0a8a5c05f476ceb1
>
> Here is the pull request
>
> https://github.com/apache/nuttx/pull/8623
>
> This pull request was written and reviewed by xiaomi (again) and only ONE
> independent review (thanks for that).
>
> No sane testing environment allows the same people to both write and
> review code ! This is not how to quality.
>
> If there are not enough independent reviewers, the pull requests should be
> either BLOCKED or sent to the mailing list for help reviewing.
>
> This would give a useful role to the mailing list.
>
> There are lots of changes incoming to the repository, it is not humanly
> possible to review them as well as Greg did in the past.
>
> I have a dayjob, I can be called out to help if need be, but I cant spend
> all my days checking everything with a critical point of view.
>
> Issues have to be communicated so we can have a look at them.
>
>
> BTW, what is wrong is this exact removal :
>
> https://github.com/apache/nuttx/commit/e6227e19433c4999d5004
> 37d0a8a5c05f476ceb1#diff-944d6d12b7cba69e3ea374135ebc541fd81
> 9308865868374776e7dc79d627195L150
>
>
> The condition by CONFIG_SCHED_HAVE_PARENT was removed. I cant find where
> the inconditional code was added. in a separate commit maybe. However, if
> that config is not set, SIGCHLD is defined by a constant in signal.h and
> not by CONFIG_SIGCHLD, as seen here:
>
> https://github.com/apache/nuttx/commit/e6227e19433c4999d5004
> 37d0a8a5c05f476ceb1#diff-944d6d12b7cba69e3ea374135ebc541fd81
> 9308865868374776e7dc79d627195R222
>
>
> Here the Kconfig shows the dependency:
>
> https://github.com/apache/nuttx/commit/e6227e19433c4999d5004
> 37d0a8a5c05f476ceb1#diff-285d196ad580d55fdaef3fbe54702ee3dde
> ed0d93cba52a5441d1866e0031726R1553
>
>
> Sebastien
>
> On 3/7/23 14:55, Gregory Nutt wrote:
>
>> It is likely that the issue with the SIGNAL number was introduced by
>>
>> commit e6227e19433c4999d500437d0a8a5c05f476ceb1
>> Author: chenrun1 <ch...@xiaomi.com>
>> Date: Wed Feb 1 17:17:43 2023 +0800
>>
>> include/signal.h:Expanding SIGNAL to be consistent with Linux
>>
>> There is nothing inherently wrong with the commit. However, none of the
>> default configurations were changed. Since the config->defconfig
>> compression removes all settings that are left at the default value,
>> changing the default value of a configuration setting effectively changes
>> the value used by the configuration.
>>
>> When the default value of a configuration setting changes in a Kconfig,
>> NuttX uses should get some kind of heads up in the dev list so that they
>> can all fix their local configurations as well.
>>
>>
Re: Build system is broken
Posted by Sebastien Lorquet <se...@lorquet.fr>.
Greg,
Thanks. The commit link is there:
https://github.com/apache/nuttx/commit/e6227e19433c4999d500437d0a8a5c05f476ceb1
Here is the pull request
https://github.com/apache/nuttx/pull/8623
This pull request was written and reviewed by xiaomi (again) and only
ONE independent review (thanks for that).
No sane testing environment allows the same people to both write and
review code ! This is not how to quality.
If there are not enough independent reviewers, the pull requests should
be either BLOCKED or sent to the mailing list for help reviewing.
This would give a useful role to the mailing list.
There are lots of changes incoming to the repository, it is not humanly
possible to review them as well as Greg did in the past.
I have a dayjob, I can be called out to help if need be, but I cant
spend all my days checking everything with a critical point of view.
Issues have to be communicated so we can have a look at them.
BTW, what is wrong is this exact removal :
https://github.com/apache/nuttx/commit/e6227e19433c4999d500437d0a8a5c05f476ceb1#diff-944d6d12b7cba69e3ea374135ebc541fd819308865868374776e7dc79d627195L150
The condition by CONFIG_SCHED_HAVE_PARENT was removed. I cant find where
the inconditional code was added. in a separate commit maybe. However,
if that config is not set, SIGCHLD is defined by a constant in signal.h
and not by CONFIG_SIGCHLD, as seen here:
https://github.com/apache/nuttx/commit/e6227e19433c4999d500437d0a8a5c05f476ceb1#diff-944d6d12b7cba69e3ea374135ebc541fd819308865868374776e7dc79d627195R222
Here the Kconfig shows the dependency:
https://github.com/apache/nuttx/commit/e6227e19433c4999d500437d0a8a5c05f476ceb1#diff-285d196ad580d55fdaef3fbe54702ee3ddeed0d93cba52a5441d1866e0031726R1553
Sebastien
On 3/7/23 14:55, Gregory Nutt wrote:
> It is likely that the issue with the SIGNAL number was introduced by
>
> commit e6227e19433c4999d500437d0a8a5c05f476ceb1
> Author: chenrun1 <ch...@xiaomi.com>
> Date: Wed Feb 1 17:17:43 2023 +0800
>
> include/signal.h:Expanding SIGNAL to be consistent with Linux
>
> There is nothing inherently wrong with the commit. However, none of
> the default configurations were changed. Since the config->defconfig
> compression removes all settings that are left at the default value,
> changing the default value of a configuration setting effectively
> changes the value used by the configuration.
>
> When the default value of a configuration setting changes in a
> Kconfig, NuttX uses should get some kind of heads up in the dev list
> so that they can all fix their local configurations as well.
>
Re: Build system is broken
Posted by Gregory Nutt <sp...@gmail.com>.
It is likely that the issue with the SIGNAL number was introduced by
commit e6227e19433c4999d500437d0a8a5c05f476ceb1
Author: chenrun1 <ch...@xiaomi.com>
Date: Wed Feb 1 17:17:43 2023 +0800
include/signal.h:Expanding SIGNAL to be consistent with Linux
There is nothing inherently wrong with the commit. However, none of the
default configurations were changed. Since the config->defconfig
compression removes all settings that are left at the default value,
changing the default value of a configuration setting effectively
changes the value used by the configuration.
When the default value of a configuration setting changes in a Kconfig,
NuttX uses should get some kind of heads up in the dev list so that they
can all fix their local configurations as well.
RE: Build system is broken
Posted by Tim Hardisty <ti...@hardisty.co.uk>.
I have been frustrated at times by changes to master and it’s a conundrum:
- If you're developing code and base it on a stable release there's a good chance that by the time your own code is "done" it will be incompatible with latest and/or the current release.
- if you develop based on current, and rebase fairly regularly, then at least you keep on top of changes as they happen and are aware and/or can comment. But sometimes it is an unwelcome diversion, so I mostly do a new branch before a rebase just in case.
Once a released candidate is released, many (hopefully) people will build and try it and vote, or comment, accordingly?
Perhaps the main issue is the one of where should changes to the "dirty master" be discussed? This mailing list as a pain as so many emails get marked as junk and I suspect many subscribers simply don't see them. GitHub, I find, is not too hard to keep on top of as at least I am committing PRs, now, fairly regularly.
Perhaps it needs a policy decision on what the two platforms intent is?
Just my two penny's worth :)
From: Sebastien Lorquet <se...@lorquet.fr>
Sent: 07 March 2023 13:12
To: dev@nuttx.apache.org
Subject: Re: Build system is broken
Hi, Do your realize how counter-intuitive this is? I would have NEVER imagined that V=0 is not the exact contrary of V=1! Can this silent mode be made optional in a config setting please? It is really a non-feature. it's just a fantasy to please some committer, and should have never been accepted imho. When I want to contribute a one liner to submit a new flash chip I get forced to wait 48 hours for useless automatic tests that will not even compile my new code, and such profound changes gets integrated immediately with almost no review other than an automatic build. I know it because some commits do not have corresponding pull requests. This gives a feeling of double standard that does not seem in line with the inviolables of this project. Tomek: Thanks, but I am not interested in workarounds that look like "here is a way to avoid asking why a change was made". Sebastien On 3/7/23 13:45, Nathan Hartman wrote: > On Tue, Mar 7, 2023 at 7:23 AM Tomek CEDRO wrote: > >> On Tue, Mar 7, 2023 at 9:24 AM Sebastien Lorquet wrote: >>> No >>> V=1 is an entirely different thing. >>> I dont want to see the output mangled with tons of arm-none-eabi-gcc >>> command lines. >>> This stuff is another breakage >>> Sebastien > > > There is V=0 which gives the same output as before. > > It needs to be documented somehow, and in a way that people will see it, or > we will get a lot of complaints and questions about it after the next > release. > > Nathan >
Re: Build system is broken
Posted by Sebastien Lorquet <se...@lorquet.fr>.
Hi,
Do your realize how counter-intuitive this is?
I would have NEVER imagined that V=0 is not the exact contrary of V=1!
Can this silent mode be made optional in a config setting please? It is
really a non-feature. it's just a fantasy to please some committer, and
should have never been accepted imho.
When I want to contribute a one liner to submit a new flash chip I get
forced to wait 48 hours for useless automatic tests that will not even
compile my new code, and such profound changes gets integrated
immediately with almost no review other than an automatic build. I know
it because some commits do not have corresponding pull requests.
This gives a feeling of double standard that does not seem in line with
the inviolables of this project.
Tomek: Thanks, but I am not interested in workarounds that look like
"here is a way to avoid asking why a change was made".
Sebastien
On 3/7/23 13:45, Nathan Hartman wrote:
> On Tue, Mar 7, 2023 at 7:23 AM Tomek CEDRO <to...@cedro.info> wrote:
>
>> On Tue, Mar 7, 2023 at 9:24 AM Sebastien Lorquet wrote:
>>> No
>>> V=1 is an entirely different thing.
>>> I dont want to see the output mangled with tons of arm-none-eabi-gcc
>>> command lines.
>>> This stuff is another breakage
>>> Sebastien
>
>
> There is V=0 which gives the same output as before.
>
> It needs to be documented somehow, and in a way that people will see it, or
> we will get a lot of complaints and questions about it after the next
> release.
>
> Nathan
>
Re: Build system is broken
Posted by Nathan Hartman <ha...@gmail.com>.
On Tue, Mar 7, 2023 at 7:23 AM Tomek CEDRO <to...@cedro.info> wrote:
> On Tue, Mar 7, 2023 at 9:24 AM Sebastien Lorquet wrote:
> > No
> > V=1 is an entirely different thing.
> > I dont want to see the output mangled with tons of arm-none-eabi-gcc
> > command lines.
> > This stuff is another breakage
> > Sebastien
There is V=0 which gives the same output as before.
It needs to be documented somehow, and in a way that people will see it, or
we will get a lot of complaints and questions about it after the next
release.
Nathan
Re: Build system is broken
Posted by Tomek CEDRO <to...@cedro.info>.
On Tue, Mar 7, 2023 at 9:24 AM Sebastien Lorquet wrote:
> No
> V=1 is an entirely different thing.
> I dont want to see the output mangled with tons of arm-none-eabi-gcc
> command lines.
> This stuff is another breakage
> Sebastien
Well if the build is silent and you do not know what happens then you
want to know what happens by enabling Verbose Build (V=1 make switch)
at least to show us the log tail with error message maybe even finding
the problem cause yourself :-)
Have you tried on a clean source tree?
If compilation takes a lot of time you can speed things up by
providing -j4 make switch to use parallel build on 4 cpu (you may want
to adjust the number up to number cpu cores on your build machine).
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Build system is broken
Posted by Sebastien Lorquet <se...@lorquet.fr>.
No
V=1 is an entirely different thing.
I dont want to see the output mangled with tons of arm-none-eabi-gcc
command lines.
This stuff is another breakage
Sebastien
On 3/7/23 09:22, Marco Casaroli wrote:
> Try
>
> make V=1
>
> On Tue, 7 Mar 2023 at 09:18, Sebastien Lorquet <se...@lorquet.fr> wrote:
>
>> Hi,
>>
>> This morning I updated my working copy, ran git pull origin master and
>> rebuilt my OS
>>
>> Now when I run make I get no output. But the cpu fan works.
>>
>> Only the last line of the console shows text, there is no log makefile
>> anymore.
>>
>> This is AWFUL!
>>
>> What happened?
>>
>> Was make updated by linux mint?
>>
>> Were makefiles in nuttx updated in such a profound way?
>>
>> I frankly dont understand.
>>
>> Sebastien
>>
>>
Re: Build system is broken
Posted by Marco Casaroli <ma...@midokura.com.INVALID>.
Try
make V=1
On Tue, 7 Mar 2023 at 09:18, Sebastien Lorquet <se...@lorquet.fr> wrote:
> Hi,
>
> This morning I updated my working copy, ran git pull origin master and
> rebuilt my OS
>
> Now when I run make I get no output. But the cpu fan works.
>
> Only the last line of the console shows text, there is no log makefile
> anymore.
>
> This is AWFUL!
>
> What happened?
>
> Was make updated by linux mint?
>
> Were makefiles in nuttx updated in such a profound way?
>
> I frankly dont understand.
>
> Sebastien
>
>