Move stamp (dependency) files outside the (version specific) source
directories, so other packages can hardcode dependencies on them instead
of having to use <PACKAGE>_VERSION variables.
This is important as the variables in the make rules are evaluated when
the rules is seen, which might be before the dependent makefile is parsed
(and hence <PACKAGE>_VERSION variable is known, screwing up stuff.
The downside of this is that the package isn't automatically rebuilt
when the version changes (E.G. by a svn update) and you now also have to
remove the stamp files next to $(BUILD_DIR)/<PACKAGE>-* to force a rebuild.
I often find myself forgetting what those targets were called, and I imagine
others may not even be aware of their existence.
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Signed-off-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
This patch will add a rule to top level Makefile to depend on the
$(PROJECT_BUILD_DIR)/autotools-stamps as a required directory. Hence it will be
generated if missing in stead of made when the $(PROJECT_BUILD_DIR)/.root rule
is triggered.
Signed-off-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
This patch will create the autotools-stamps directory early in the build
process, thus making it possible for non Makefile.autotools.in packages to use
this directory to hold stamp files.
Signed-off-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
HOST_GLIB is set to the path that contains the host glib tool set and is
used when building packages using glib. The buildroot top level Makefile
sets HOST_GLIB using which to find the path where glib-genmarshal is
located.
The problem is that a cross compiled version of glib-genmarshal is also
put in the build_ARCH/staging_dir/usr/bin directory when the package
libglib2 is built. This cross compiled version will typically not run on
the host system.
Fix it by ignoring staging_dir in the which output.
Closes#5934
jacmet: fixed to work correctly if it's only found in staging_dir.
Improve external toolchain support
* Do not put kernel-headers in the dependencies of BASE_TARGETS in
the case where BR2_TOOLCHAIN_SOURCE is not y. The kernel headers
are already supposed to be part of the external toolchain, so
there's no need to download, extract and install them.
* In the configuration system, don't display the kernel headers
version selection list when an external toolchain is selected. This
is implemented by moving the source
"toolchain/kernel-headers/Config.in" inside the if
BR2_TOOLCHAIN_SOURCE in toolchain/Config.in.2.
* Change the description and help message of the BR2_LARGEFILE,
BR2_INET_IPV6, BR2_INET_RPC, and BR2_SOFT_FLOAT option in
toolchain/external-toolchain/Config.in. In the case of an external
toolchain, the semantic of these options is not to enable large
file support, IPV6 or RPC (since the toolchain is already compiled,
it has been decided previously). Their semantic is to let Buildroot
know about the characteristics of the external toolchain being
used.
As an improvement, we could guess these values automatically:
- for BR2_LARGEFILE, look at the value of __UCLIBC_HAS_LFS__ in
bits/uClibc_config.h in the libc headers directory.
- for BR2_INET_RPC, look at the value of __UCLIBC_HAS_RPC__ in the
same file
- for BR2_INET_IPV6, look at the value of __UCLIBC_HAS_IPV6__ in
the same file
- for BR2_SOFT_FLOAT, look at the output of $(CC) -v 2>&1 | grep
-- "--with-float=soft"
But I'm not sure how this would be possible, since these values are
used at configuration-time by other configuration options, not only
at build time.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
make "make clean" remove the .root stamp, so that everything will
be reinstalled properly on a subsequent build. (bug id 4304)
Also remove new autotools-stamps directory.
The MAKELEVEL test is not that robust; It fails with the recent log
support or if buildroot is driven from an external Makefile.
Rework it to instead detect source-check/external-deps by the fact that
they set SPIDER.
Mark empty directories in target skeletons with .empty files
and remove them while copying to target (like it's already done for
svn and cvs files) to better support version control system which don't
handle empty directories (E.G. git-svn).
Will need to try to copy eventual pre-existing project-specific deps back
to package/config in order not to mess up the corresponding timestamps (to avoid superfluous rebuilds)..
=========================================================
The purpose of the BSP patch is to allow building
several boards inside the same buildroot tree.
For this to work, each board has to have its
own "$(TARGET_DIR)" and all *configurable* packages
must be rebuilt for each board.
They are now built in the "$(PROJECT_BUILD_DIR)"
All non configurable packages can and should still
be built in the "$(BUILD_DIR)".
If a package is built for one board, then when
you build for a second board of the same architecture
the build becomes a simple copy of the resulting
binaries.
-----
Define BR2_PROJECT which will be used as the selector
between different boards. Note that BR2_PROJECT allow
you to build multiple root file systems for a single
board, and should not be confused with BR2_BOARD_NAME
which relates to the H/W.
-----
Define PROJECT_BUILD_DIR as "PROJECT_BUILD_DIR/$(PROJECT)"
Define BINARIES_DIR as "binaries/$(PROJECT)"
Define TARGET_DIR as "$(PROJECT_BUILD_DIR)/root"
(some prefix/postfix may apply)
Resulting images are stored in "$(BINARIES_DIR)"
-----
Define a few new environment variables in Makefile
PROJECT: Stripped BR2_PROJECT
DATE: Date of build in YYYY-MM-DD format
HOSTNAME: Stripped BR2_HOSTNAME => /etc/hostname
BANNER: Stripped BR2_BANNER => /etc/issue
Linux and Busybox will be built in $(PROJECT_BUILD_DIR)
More patches will be needed later to ensure all
configurable packages are built in this directory.
