summaryrefslogtreecommitdiff
path: root/scripts/build/companion_tools/200-autoconf.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-11-28Add DTC as a companion toolAlexey Neyman1-5/+10
(needed for cross-gdb targeting the moxie-* targets) Signed-off-by: Alexey Neyman <stilor@att.net>
2017-07-08Fix the references to old config variablesAlexey Neyman1-6/+3
Signed-off-by: Alexey Neyman <stilor@att.net>
2017-01-25Run all configure scripts using ${CONFIG_SHELL}Alexey Neyman1-1/+2
... as its help message says in menuconfig. Signed-off-by: Alexey Neyman <stilor@att.net>
2017-01-24Fix loglevel for steps in companion toolsAlexey Neyman1-2/+2
(was EXTRA, should be INFO to be consistent with the rest). Signed-off-by: Alexey Neyman <stilor@att.net>
2016-12-02Add 'companion tools for host' step.Alexey Neyman1-8/+25
Signed-off-by: Alexey Neyman <stilor@att.net>
2016-12-02Move companion tool build into a separate step.Alexey Neyman1-1/+6
Also, rename "build" -> "for_build", since we're going to have a "for_host" as well. Signed-off-by: Alexey Neyman <stilor@att.net>
2016-11-22Give companion tools some love.Alexey Neyman1-2/+0
Allow selection of make/m4/... version. Support imports of new versions via addToolVersion.sh. Import newest versions of the companion tools. One non-trivial change is the handling of make versions. Existing code was not handling make companion tool as described (see the previous commit). However, since most modern systems have make 4.x, that previous commit made crosstool-ng always build make as a companion tool. This traces back to the commit dd15c93 from 2014. That commit's log message says that actually it was 3.81 which broke the build for certain component (it was originally breaking eglibc, but I noticed it was breaking current glibc on powerpc64), and introduced an option to force using 3.81 by "components that really need it". It looks like in 2.5 years we haven't seen any such components that really need make 3.81, and (given that make has already had a few releases since 3.81) we're unlikely to see them in the future. Hence, the configure check is changed from "exactly 3.81" to "3.81 or newer". In its current form, configure will accept make 3.80+, and will not require make as a companion tool for 3.81+. We might want to bump the latter check to even newer version given the claim from dd15c93. Killed COMP_TOOLS_make_3_81_NEEDED. Anyway, I retained 3.81 just in case; ditto for m4 1.14.3, autoconf 2.65 and automake 1.11.1. Signed-off-by: Alexey Neyman <stilor@att.net>
2016-11-21Partially revert 6f8e89cb5ca061e899bf3feaaf3fecf30d366c3e.Alexey Neyman1-2/+2
The referenced commit replaced 'make' with '${make}' everywhere. This is wrong for at least the utilities that we may build as companion tools (make, libtool): this will always invoke the version detected by configure by supplying the absolute path. In other words, the wrappers in .build/tools/bin are not fallbacks - they are either temporary (in case a respective companion tool is built) or permanent redirectors. This is the reason why the PATH= has .build/*/buildtools/bin at higher precedence than .build/tools/bin; the latter has the versions detected by configure and the former has the versions built as companion tools. Revert the rest of the gang (grep/sed/...) for consistency. After all, we may decide to supply some of them as well (awk, for instance). Signed-off-by: Alexey Neyman <stilor@att.net>
2015-11-17consistency: Use exported variables of required toolsBryan Hundven1-2/+2
We check for apps: * make * sed * grep * awk * libtool/libtoolize * install * patch * and more ...during configure. Our scripts should be consistent about using the variables that define where the found tool was found. Of course, we do hard-link these tools in buildtools, but that should be a backup for the components we are building. Our scripts should always use the tools we find. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2014-12-08scripts: Update download locationsBryan Hundven1-2/+2
This change updates the download locations to default to the official download site. For gcc and gdb, also separate out the linaro download locations so that if you are downloading the linaro variant, it skips trying to download from the official gcc mirror. This commit closes #3 Signed-off-by: Bryan Hundven <bryanhundven@gmail.com> Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2011-03-03comptools/autoconf: chmod files to u+wYann E. MORIN"1-0/+1
The autoconf-2.65 tarball contains RO files. We have to chmod them u+w. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-12-18comptools: install them side-to-side with build toolsYann E. MORIN"1-2/+2
As companion tools might or might not be used to build each toolchain, they do belong to that toolchain's build tools, not to the generic override tools. Fix a typo in the autoconf URL. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-10-22scripts: add "FILE" and "CFG" debug levels.Anthony Foiani1-1/+1
I ran into some minor difficulties looking through the build log for a particular file: I wasn't interested in seeing it unpacked, but only when it is built or installed. Adding these two levels allows me to differentiate between those cases. [Yann E. MORIN: Those are blind log levels, and are used only to search in the build-log afterward.] Signed-off-by: Anthony Foiani <anthony.foiani@gmail.com>
2010-04-11scripts/functions: make CT_Patch dumberYann E. MORIN"1-1/+1
It is the responsibility of the caller to split the package name from its version. It already knows that.
2010-01-12companion_tools/autoconf: add autoconf toolYann E. MORIN"1-0/+32
Initial version of adding autoconf as a companion tool. Signed-off-by: Richard Strand <richard.strand@icomera.com> [yann.morin.1998@anciens.enib.fr: use generic overide tools dir] [yann.morin.1998@anciens.enib.fr: update menu entries] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>