Re: [RFC] Refactor autoconf options and build scripts

["Jasmin J." <jasmin at anw dot at>]

Hello!

> 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.
This might make the build scripts easier, but Kconfig gets more complex.
You are right, that you can model dependencies more easy with Kconfig, but I
hope it will not grow into a mess with time.

> config CC_CXA_ATEXIT_CONFIG
>     string "--enable-__cxa_atexit"
>     depends on CC_CXA_ATEXIT
> else # ! CC_CXA_ATEXIT

During my work on arm-none-eabi, I discovered a lot of configurations, which
are already the default (at least for my used source versions) and I would
have been able to remove the option, which was not possible currently.

If someone likes to remove such an option completely, it might be useful to
define it so:
config CC_CXA_ATEXIT_CONFIG
    string
    prompt "enable atexit option"
    default "--enable-__cxa_atexit"
    depends on CC_CXA_ATEXIT
else # ! CC_CXA_ATEXIT

At least this can be done for some of the configurations where it seems to
be appropriate.

On the other hand we will duplicate some definitions. Most of the options
are needed for the first GCC and a second time for the final one. I am sure
it doesn't make sense to duplicate all, but for some it have to be done. One
example would be the supported languages (lang_list).
Or would you like to keep some things hard coded?

> 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.
You mean the download, extract, patching, ... . So one generic basic script
(like a base class in c++) for all of this steps. Sounds like a good concept.
If you are interested in OO-Bash (never tried it):
-
http://hipersayanx.blogspot.co.at/2012/12/object-oriented-programming-in-bash.html
-  https://github.com/tomas/skull

Would you like to do this in steps or all at once?
Would you like to code it on your own or shall other people help?
If the latter, how would you like to distribute the work?
How can we be sure the new version does still build all the supported variants?
Are there regression testing scripts/configurations available?

BR
   Jasmin

*************************************************************************

On 09/08/2015 07:32 PM, Bryan Hundven wrote:
> List,
> 
> 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
> ==========================================================
> 
> Then in the scripts/build/cc/100-gcc.sh, it would only have an override like:
> ==========================================================
> CONFIGURE_OPTS += ${CT_CC_CXA_ATEXIT_CONFIG}
> ==========================================================
> 
> 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.
> 
> Cheers,
> 
> -Bryan
> 
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
> 

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