This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See crosstool-NG for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |