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
possible to differentiate all the jam-versions out there...
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@18505 a95241bf-73f2-0310-859d-f6bbb57e9c96
children (as created by piped commands). This caused the compilation
of AboutHaiku to fail on Zeta.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@18503 a95241bf-73f2-0310-859d-f6bbb57e9c96
In fact, BeIDE seems to delete the entry and move a temp entry to the right place:
StatCacheServer was then thinking that the entry was removed
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@17926 a95241bf-73f2-0310-859d-f6bbb57e9c96
