Re: [RFC] Refactor autoconf options and build scripts

[Bryan Hundven <bryanhundven@gmail.com>]

Thomas, Jasmin, all,

On Sat, Sep 12, 2015 at 11:03 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Bryan,
>
> On Tue, 8 Sep 2015 10:32:20 -0700, Bryan Hundven wrote:
>
>> Crosstool-NG has become a very useful and valuable tool for creating
>> custom GCC based toolchains, and over time a lot of new features have
>> been added.
>>
>> The addition of features, and the complexity of options each component
>> can support makes developing new features (multi_cc, multiple
>> different libcs, new targets, new hosts, etc...) very difficult.
>>
>> A large majority of components Crosstool-NG builds utilize the
>> autotools build approach, and have a multitude of different options
>> that may have many external dependencies. These dependencies are
>> difficult at best to track in one build script, let alone across many
>> scripts.
>>
>> My first proposal on re-factoring Crosstool-NG is to move these
>> autoconf arguments (--with-options) to Kconfig options/strings that
>> can be selected or depended on by other components and move them out
>> of the build scripts to additionally simplify the build scripts.
>>
>> For instance:
>>
>> https://github.com/crosstool-ng/crosstool-ng/blob/master/scripts/build/cc/100-gcc.sh#L242
>> ==========================================================
>>     if [ "${CT_CC_CXA_ATEXIT}" = "y" ]; then
>>         extra_config+=("--enable-__cxa_atexit")
>>     else
>>         extra_config+=("--disable-__cxa_atexit")
>>     fi
>> ==========================================================
>>
>> Could turn into:
>> ==========================================================
>> if CC_CXA_ATEXIT
>> config CC_CXA_ATEXIT_CONFIG
>>     string "--enable-__cxa_atexit"
>>     depends on CC_CXA_ATEXIT
>> else # ! CC_CXA_ATEXIT
>> config CC_CXA_ATEXIT_CONFIG
>>     string "--disable-__cxa_atexit"
>>     depends on !CC_CXA_ATEXIT
>> endif # CC_CXA_ATEXIT
>> ==========================================================
>
> I am really unsure this is making things simpler. I personally find
> this in fact more complicated to understand.
>
> However, what I think makes Crosstool-NG overly complicated is the way
> too large number of options. There should be some rationalization:
> support only a smaller subset of the gcc/binutils/C library versions,
> remove seldom used configuration options, etc.

I agree with this. I guess that's why it's an RFC :)

> This profusion of config options also means that a lot of combinations
> are not tested and do not build. My personal experience with
> Crosstool-NG, and the feedback from several users on the list is that
> you very often get build failures when you start toggling options.

Well, I can admit that I have committed updated versions of newer
components without testing all combinations, let alone all samples. I
have also merged PR with out checking if the developer has as well. I
really need a computer where I can run build tests on. Yann has given
me access to one he uses for building, and I need to get time to sit
down and get some build tests going, for at least the samples/
directory.

I would also hope in that testing that I might be able to expose and
to utilize a randconfig for ct-ng. This would help to build random
configs and find combinations of options that should have constraints.

> For
> example, Crosstool-NG does not ensure that the proper cloog/mpc/gmp
> version is selected for a given version of gcc (solution: make the
> version of those components not configurable).

With current master, I know this to be true. I need to be more strict with PRs.

>> My second proposal is to refactor the build scripts themselves into a generic
>> build script. Then the current build scripts (i.e.: scripts/build/cc/100-gcc.sh)
>> would override variables and functionality in the generic build script, as
>> needed.
>>
>> The benefits of making the build scripts more generic and moving the
>> configuration options out of the build scripts would allow for Crosstool-NG to
>> become more flexible for future development.
>
> I think you might be confusing complexity with length. The current build
> scripts may be long, but if it's just a list of:
>
>     if [ "${CT_CC_CXA_ATEXIT}" = "y" ]; then
>         extra_config+=("--enable-__cxa_atexit")
>     else
>         extra_config+=("--disable-__cxa_atexit")
>     fi
>
> Then it is trivial to understand. If you replace that by something
> "generic" that is shorter but in fact trickier to understand, there is
> no real benefit.

I don't feel that I expressed myself fully, and will re-write my RFC
with a better plan. I still see the value in what I mean, I just don't
think I thought it through enough before sending it.

I appreciate your comments! I will keep those in mind while I rewrite.

> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

--
For unsubscribe information see http://sourceware.org/lists.html#faq