Based on Boost Jam patch: https://github.com/boostorg/build/pull/133
retrofitted to our version. Only the rules whose name contains Cc or C++
are stored there. This can be improved if it's not good enough.
The commands are generated only as they are run. Unfortunately I think
with Jam there isn't really a way to do otherwise.
Change-Id: Ic5d44dc27baa2a2e4157324f6c5a228ab0366afe
Reviewed-on: https://review.haiku-os.org/c/buildtools/+/3260
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This brings Jam's usage of AR to be more conventional: the flags for AR
are moved to a separate variable, called ARFLAGS, ensuring that any
environment that overrides the AR variable will still end up using the
correct flags to create the archve.
Change-Id: I00449b284fab132d5fc9239017d742480fb51820
Reviewed-on: https://review.haiku-os.org/c/buildtools/+/3226
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Make new_string_list() initialize the buffer it creates to hold a file's
contents, preventing a segfault later on should jam attempt to parse the
contents of an empty file.
Fixes#15250.
Change-Id: I907dccd26e1ca35fbe07ed6d624b0144487134fe
Reviewed-on: https://review.haiku-os.org/c/buildtools/+/1716
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
On most systems, "D" (deterministic) is now the default archiving mode,
and so specifying "u" will throw a warning that "D" is being used anyway.
Jam previously assumed, as it was passing "u", that the timestamps inside
.a's were valid when they were actually 0, which was leading to spurious
rebuilds of .as.
After this change, we assume archives cannot be scanned for timestamps,
which should stop the spurious rebuilds of targets on most systems.
Hopefully this is enough to satisfy the license requirements.
Remove some of the "LOCAL CHANGE" comments as a result (ones about
the HeaderCache remain.)
I had jam crash in strange ways because a stack-allocatted aray was
overflowing. Double the limit, and add sanity checks with exit and clear
error messages in case it happens again.
If setting OPTIM by jam basically makes it impossible for the project that
is using jam to set its own optimization level while still allowing user
to override that in command line. For example in Haiku jam files there is
line like this: "OPTIM ?= -O2", which obviously is meant to set optimization
level to O2 unless user overwrites it. Unfortunately, because Jam have already
set OPTIM to -O this line never had an intended effect.
After this Jam no longer thinks it knows best what is good for projects
that are using it and Haiku is by default compiled with -O2.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
Looks like it wasn't enough yet after the PM merge.
However we still have an issue with a silently failed Link action
which actually is smaller than the max line size...
For its input files jam uses a buffer of 512 chars for fgets(). Lines
would therefore be split silently after that length, which could lead to
"interesting" issues. Now we fail to prevent the situation from going
unnoticed.
When reading the cache file failed we have to assume it is corrupt and
we should use any entries read from it. So now we remove the ones we
read again.
* This changes the optimization level from -O3 to -O
* This will prevent segfaults when creating jam via the Makefile on FreeBSD
* Benchmarking was done, and there seems to be no negative performance impact
* Another option would be -O3 -fno-strict-aliasing, but this has no noticeable benefit over -O
It should probably be a command line option as it might be interesting in some cases.
Also added a "Build Failure" at the end if there were failed targets.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@41294 a95241bf-73f2-0310-859d-f6bbb57e9c96
* On Haiku, the jam install folder should be /boot/common.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@32875 a95241bf-73f2-0310-859d-f6bbb57e9c96
* A Node can no longer have a referring "." or ".." Entry (except the root
directory), not even temporarily. This rules out cycles when resolving
paths.
* Made the code more robust against missed node monitoring messages. If
an entry is encountered that shouldn't be there, it is removed. As
implemented before, a Node could end up with a NULL referring Entry,
leading to a crash when an Entry that references the Node was moved.
Missing node monitoring messages is actually virtually impossible,
since a dedicated looper does nothing else but pushing those into a
separate queue, but nevertheless Stippi seems to have managed the trick. :-)
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@21307 a95241bf-73f2-0310-859d-f6bbb57e9c96
