When asked to strip binaries when copying to containers we now
strip to a temporary file, copy over resources to it, copy it
to the container, then copy the attributes from the original
source.
This should allow stripping binaries while preserving attributes
and resources even when copying to images.
We now only attempt to strip binaries, by detecting the
LINKFLAGS variable on the targets.
CopySetHaikuRevision now also forwards LINKFLAGS
to revisioned binaries.
Introduce separate AppendToContainerCopyFilesScriptStripFile actions
which are used for copying and stripping, and avoids many useless
shell tests.
When asked to strip binaries, they are detected and handled
individually for simplicity.
Note we still don't keep resources and attributes when stripping.
This makes it fit again.
We can't reference in BuildSetup a variable set with the other
ones in KernelArchitectureSetup since the rule is invoked later.
The developer building the packages should enter their own address
instead. I just noticed that a lot of the HaikuPorts package have a
packager attribute with the dummy address "The Haiku build system
<build-system@haiku-os.org>" due to the previous default value.
Currently only needed for boot floppy on some platforms.
Disabled for now.
Note we do not have a mean of knowing which file is a binary
or not so we just try to strip, and silently continue when
strip fails (like on the kernel settings file).
Also note strip actually replaces the file, which means it looses
both the resources and attributes, which shouldn't be a problem
for the boot floppy drivers archive, but is not wanted for other
images, so it's not usable elsewhere as such. Patch wanted.
* rule AddPackageFilesToHaikuImage: Add "flags" parameter. The only
supported flag is "nameFromMetaInfo". It causes the packages to be
copied under their canonical file name onto the image.
* Use the new flag for all generated packages save haiku_loader.hpkg.
* Add "flags" parameter and only supported flag "computeName". When
specified the "destName" argument is the name of a shell command
or function that will be called to determine the destination file
name when the container is built.
* AddFilesToHaikuImage: Pass flags to AddFilesToContainer.
Instead of listing all the objects we want from the libgcc archive
we just make a copy of it and remove those we don't want, and link
to it.
This should allow returning MAXLINE in jam to a sane value.
This makes package management operations that require a repository cache
immediately usable (even offline). Also makes sense for the
update-{all,packages} build profile actions, since those update the
repository config which would otherwise no longer match a potentially
existing cache.
... before copying the new contents to the image. This caters to the
typical use case of updating an existing Haiku, making manual
intervention to get the new packages activated unnecessary. The downside
is that manually added packages will be removed as well.
If additional parameters are specified, only those targets are built,
but under the influence of the build profile. E.g. "jam @alpha-raw build
haiku.hpkg" builds the package with SSL support, while "jam haiku.hpkg"
would build it without (unless explicitly enabled in UserBuildConfig).
* find_directory() and hard-coded paths use /boot/system instead of
/boot/common.
* The build system creates the writable directories in /boot/system
instead of /boot/common.
* The build system no longer installs any packages in /boot/common.
* This was a script relying on a working /etc/profile, which may not be
there
* Instead, use GNU which, available as an haikuport recipe
* Since the command does not seem to be needed for Haiku to run (and
also because I don't know how to do it), GNU which isn't in the default
install.
* Typing "which" in a terminal still works, as that uses an alias
defined directly in /etc/profile.
Declare a HOST_PTHREAD_LINKFLAGS variable to hold the flags
required to link with pthreads, and use it for the solver addon.
Works on GNU/Linux, please test and fix for other platforms.
* only the source package are actually relevant, as the source paths
within older versions of those source packages no longer match the
expectations of the build system
Latest gcc converts the old ones to the new ones anyway...
including when passing to gas, which of course is not new enough,
so we have to also force gcc to pass the old one around in one case.
