Re: [DISCUSS] Out-of-tree builds should be standard? -> no

[Sebastien Lorquet <se...@lorquet.fr>]

Hello

Why should you change the experience and make life difficult for 
everyone, just to support a pair of specific configuration?

If you need to build twice, build twice, one project for h7, one project 
for m4, then one python or other script to combine the images.

All users matter (eg, not just the little comfort of AMP users) This is 
in inviolables.txt

Sebastien

Le 24/08/2023 à 21:28, Nathan Hartman a écrit :
> PR # 10328 is bringing support for STM32 MCUs that have two different kinds
> of cores on chip: Cortex M7 and Cortex M4. In other words, AMP-style
> (Asymmetric Multi Processing) chip. This requires building NuttX twice,
> once for each core, with two different configs.
>
> In the GitHub comments, it was mentioned that we should not make cmake
> mandatory for certain boards, and then mentioned that with make the problem
> is that you have to make distclean between the two builds. Copying the
> comments here:
>
> slorquet writes:
>
>>> It would be good to avoid cmake-specific features.
>>> Is make a supported build system or was it deprecated?
>>> If it's supported no feature should work only with cmake. Thanks.
> xiaoxiang781216 writes:
>
>> The change should work with make too. But make doesn't support out of
> tree build, it's very annoying to develop AMP system like this patch
> because you have to `make distclean` and `make` every time.
>
> This makes me wonder whether we should consider making out-of-tree builds
> the blessed way to build, with both make and cmake.
>
> I realize that this might disrupt many people's builds -- including myself.
> I have been building in-tree from the start, so this will require me to
> change my workflows.
>
> However, after the dust settles, this could have several advantages:
>
> 1. Not polluting the source tree with build artifacts and temporary files.
>
> 2. Simplifying the.gitignore rules throughout.
>
> 3. Allowing AMP builds and builds for multiple different boards without
> make distclean. To switch between boards, just change to a different build
> dir.
>
> I am starting this thread here because this kind of proposal really needs a
> discussion on the mailing list.
>
> Thoughts?
>
> Cheers
> Nathan
>

Re: [DISCUSS] Out-of-tree builds should be standard? -> no

[Sebastien Lorquet <se...@lorquet.fr>]

Others selected parts of inviolables.txt :


All support must apply equally to all supported platforms. At present 
this includes Linux, Windows MSYS, Windows Cygwin, Windows Ubuntu, 
Windows native, macOS, Solaris, and FreeBSD. No tool/environment 
solutions will be considered that limit the usage of NuttX on any of the 
supported platforms.

Inclusive rather than exclusive.

Hobbyists are valued users of the OS including retro computing hobbyists 
and DIY “Maker” hobbyists.

No changes to build system should limit use of NuttX by any user.

We must resist the pull to make NuttX into a Linux-only, GCC-only, and 
ARM-only solution.


So the question asked in this thread should be answered : No, out of 
tree builds should not be standard.


Sebastien


Le 25/08/2023 à 09:38, Sebastien Lorquet a écrit :
> Hello
>
> Why should you change the experience and make life difficult for 
> everyone, just to support a pair of specific configuration?
>
> If you need to build twice, build twice, one project for h7, one 
> project for m4, then one python or other script to combine the images.
>
> All users matter (eg, not just the little comfort of AMP users) This 
> is in inviolables.txt
>
> Sebastien
>
> Le 24/08/2023 à 21:28, Nathan Hartman a écrit :
>> PR # 10328 is bringing support for STM32 MCUs that have two different 
>> kinds
>> of cores on chip: Cortex M7 and Cortex M4. In other words, AMP-style
>> (Asymmetric Multi Processing) chip. This requires building NuttX twice,
>> once for each core, with two different configs.
>>
>> In the GitHub comments, it was mentioned that we should not make cmake
>> mandatory for certain boards, and then mentioned that with make the 
>> problem
>> is that you have to make distclean between the two builds. Copying the
>> comments here:
>>
>> slorquet writes:
>>
>>>> It would be good to avoid cmake-specific features.
>>>> Is make a supported build system or was it deprecated?
>>>> If it's supported no feature should work only with cmake. Thanks.
>> xiaoxiang781216 writes:
>>
>>> The change should work with make too. But make doesn't support out of
>> tree build, it's very annoying to develop AMP system like this patch
>> because you have to `make distclean` and `make` every time.
>>
>> This makes me wonder whether we should consider making out-of-tree 
>> builds
>> the blessed way to build, with both make and cmake.
>>
>> I realize that this might disrupt many people's builds -- including 
>> myself.
>> I have been building in-tree from the start, so this will require me to
>> change my workflows.
>>
>> However, after the dust settles, this could have several advantages:
>>
>> 1. Not polluting the source tree with build artifacts and temporary 
>> files.
>>
>> 2. Simplifying the.gitignore rules throughout.
>>
>> 3. Allowing AMP builds and builds for multiple different boards without
>> make distclean. To switch between boards, just change to a different 
>> build
>> dir.
>>
>> I am starting this thread here because this kind of proposal really 
>> needs a
>> discussion on the mailing list.
>>
>> Thoughts?
>>
>> Cheers
>> Nathan
>>

Re: [DISCUSS] Out-of-tree builds should be standard? -> no

[Tomek CEDRO <to...@cedro.info>]

On Fri, Aug 25, 2023 at 9:38 AM Sebastien Lorquet wrote:
> If you need to build twice, build twice, one project for h7, one project
> for m4, then one python or other script to combine the images.

Some thoughts on this part :-)

Yes, I agree here, and also proposed that with a several examples.

New script would be a proof of concept if that kind of build is
possible and how things work in reality.

New script would be addition and non invasive functionality.

New script would not flip all make build system upside down with a
possibility of breaking backwards compatibility because build system
remains untouched.

New build script may create out-of-tree copy of the sources and
configuration for a specific make build then link the results into a
single firmware image.

New script may leverage new cmake build with out-of-tree objects and
binaries if make build is not good enough.

New script, when verified and accepted, can be added to the upstream,
providing additional optional functionality, just as most new things
are added - use only when needed and stay in harmony with what is
already here.

I also use build scripts in my projects.

New script is a good first step to prove if this kind of build is
possible. If that works and author has time to update make build
system with a new out-of-tree features _that_will_not_break_anything_
and _provide_full_backwards_compatibility_ (I gave FreeBSD build
system as an example) that would seem to be time to discuss the
_non_breaking_ change when we have something to discuss on. But this
seems really lots of work that can be spared with a simple additional
optional script. There are lots of ways to achieve the goal, in theory
anything is possible, in reality it is always matter of
work-time-cost.

Not sure if that sounded clear enough in my previous reply, but this
kind of build seems already possible, I work that way, with a
different approach to build and project organization and zero upstream
modifications.

Why change the defaults for everyone because of a specific setup?

Defaults should stay untouched :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info