[RFC] Refactor autoconf options and build scripts

[Thomas Petazzoni]

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.

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. 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).

> 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.

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