Re: [RFC] Refactor autoconf options and build scripts

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

Thomas,

> support only a smaller subset of the gcc/binutils/C library versions,
> remove seldom used configuration options, etc.
My main goal is use CT-NG to build an arm-none-eabi compiler. This is currently
not full supported by CT-NG, at least with all the options the original build
script is using. But I am very happy to have all the current options and
selections which makes my life easier.

A solution might be to enable some of the options only in experimental mode or
to introduce a new mode, which allows only a few version combinations. If the
new "Expert Mode" is selected, then you will get all the options to change the
versions.

> For example, Crosstool-NG
> does not ensure that the proper cloog/mpc/gmp version is selected for a
> given version of gcc
At least for ClooG/isl I just implemented this. But you are right, who has the
time to check all the possible combinations.

> 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.
100-gcc.sh uses "do_gcc_core_backend" for both the core and the final gcc,
when building for bare-metal. I don't know why, but the do_gcc_core_backend
function does not set the options for libssp and libquadmath and the handling
of "CT_CC_GCC_USE_LTO" is different, too.
So a generic "base class" for the gcc build might help to reduce such
inconsistencies, because I guess this difference for both compilers is not
intended.

I guess it depends how Bryan wants to implement the generic script and how it
can be tailored in the specific script. For example, I want to build newlib
in two variants. This requires an additional build step "newlib-nano". However
I will implement this, it is a complete copy of the newlib step with only 2..3
options changed/added. Having here a generic build script would reduce the work
to implement this.

> Now that you've moved to github for the code, maybe
> https://travis-ci.org might help (at least for the non-randconfig cases)?
Although this is intended for program regression tests, it can be used for
CT-NG with this options (I guess):

before_install:
	- sudo apt-get update -qq
	- sudo apt-get install -qq [packages list]
 -> used to install the packages required for CT-NG

install: ./tests/config_cg_ng.sh
 -> will do bootstrap, configure --enable-local and make

script: ./tests/run-tests.sh
 -> will execute CT-NG with the predefined configurations

Note:
 a) ./tests is a new subdirectory for the travis-ci scripts.
 b) Someone needs to define predefined configs for the different variants to
    test and enter them into run-tests.sh

Got this info about the configuration from here:
  http://docs.travis-ci.com/user/customizing-the-build/

BR
   Jasmin

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