Rather than building all possible library names in the caller,
lets just do it once in check_for.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Static liunking is not supported on Darwin, so hide the corresponding
options when the build machine is Darwin.
Reported-by: Andrea Franceschini <therealmorpheu5@gmail.com>
Reported-by: Bryan Hundven <bryanhundven@gmail.com>
Reported-by: "Titus von Boxberg" <titus@v9g.de>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Indent the error/warning message so that it is explicit that
the second line is giving details for the first general hint.
Reported-by: Titus von Boxberg <titus@v9g.de>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
./configure now has the possibility to check for libraries and headers
in one go, so we can use it! :-)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Cross-gdb depends on expat and python. If either is missing, cross-gdb will
build successfully, but lacking some features.
Especially, if expat is missing, cross-gdb will be unable to parse the target
description, which may lead to runtime malfunctions and the following GDB
warning:
"Can not parse XML target description; XML support was disabled at compile time"
Hence, expat should be considered mandatory.
On the other hand, the features missing without python are not critical, so
python should not be considered mandatory.
This patch does the following:
- At configure time, warn the user if either expat or python is missing.
- In menuconfig, disable the static build options regarding cross-gdb if no
static version of expat is available, and disable cross-gdb if expat is
missing.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
[yann.morin.1998@anciens.enib.fr: add comment for impossible static cross-gdb]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, check_for() can only test one of prog, inc or lib at once. This patch
removes this limitation.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
Currently, error messages just state the obvious: a required
component is required. While in some cases, there is not much
else to say, in some other cases we could tell much more.
For example, a missing libstdc++ means no static toolchain.
Also, format error and warning messages in a similar fashion,
with a {error,warning} intro, followed by the message specified
by the caller.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Hide the staticaly linked libstdc++ option if the static libstdc++ is not
present, detected at configure time.
Add a blind option that says whether static linking is possible at all.
It defaults to 'y', but depends on the needed CONFIGURE_* options. For
now, it only depends on static libtdc++, but new dependencies can be
easily added.
Hide the global static toolchain option behind this new option.
Original patch by Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It's probably a good thing to check for at least one instance of
libstdc++.{so,dylib,a} at configure time. At least one is needed
by the companion libraries and gcc.
Original patch by Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
If check_for is able to find the required prog/inc/lib, allow it to
set an arbitrary variable to 'y'. This variable is then pushed down
to the kconfig definition.
For example:
has_or_abort prog=foobar kconfig=has_foobar
If foobar is available, it yields a kconfig variable defaulting to y:
config CONFIGURE_has_foobar
bool
default y
If foobar is missing, it yields a kconfig variable defaulting to n:
config CONFIGURE_has_foobar
bool
Thus it is possible to depends on that variabel to show/hide options:
config SOME_FEATURE
bool
prompt "Some feature"
depends on CONFIGURE_has_foobar
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When has_or_warn will come, we do want to print the error message
only in has_or_abort, so move it down there.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When configuring in an hg clone, we need hg to compute the version string.
It can happen that users do not have Mercurial (eg. if they got a snapshot
rather that they did a full clone). In this case, we can still run, of
course, so simply fill the version string with a sufficiently explicit
value, that does not require hg. The date is a good candidate.
aria2 is a powerfull downloader that is capable of chunking and
parallel retrieval.
Due to li;itations in crosstool-NG retrieval facilities, it's not possible
to take fully advantage of aria2. It might happen that, in the future,
those limitations get lifted away, so we can take use features such as
parallel downloading from more than one server at the same time. For now,
it should still speed up downloads thanks to parallel downloading of chunks.
In case the user specifies the LIBDIR with --libdir , or DOCDIR with
--docdir, install our support files in a sub-dir, so as not to mangle
existing (potentially system) files/dirs.
Split the has_or_abort function in two:
- one that checks if the tool if found,
- one that calls the above check, and aborts if not found
The rational behind this is to be able to check for a tool
and if not found, fallback to using our bundled version,
should the need arise (and I get time).
For every components where it makes sense, use bash arrays (instead
of a string with space-separated values) to store the options pased
to ./configure.
The configure script fails on automake-1.11 (in Fedora-11) since
it looks for 3-digit version number.
Patch fixed by "Yann E. MORIN", with the added comment:
The check for the automake version is not against a 3-digit number,
but really against a 3-part version number, a-la 'x.y.z'. Versions
such as 1.10 and 1.11 are also valid.
Now that we have migrated to hg from svn, it does not make sense
to keep using svn tools to compute the version string, so switch
to using mercurial tools (that are much more flexible, BTW).
