This lets us remove the awkward ". ./redoconf.rc" line from zillions
of .od scripts, without paying the price of *always* including that
whole file every time default.do.sh is used.
- libqt4.rc: add detection of the 'moc' command in $MOC.
- libssl.rc: add detection script for openssl.
- default.do.sh: provide a die() function to all .od files. It's just
too useful to not have it (I haven't converted everything to it yet).
- When building out/x/y.z, match against $S/default.z.od and
$S/default.od if they exist.
- *.list files (lists of source/object files to include in a binary)
can now contain *.o files in addition to *.c, *.cc, etc.
- rename compile() to _compile() to avoid polluting the namespace for
scripts called from default.do.sh.
- When building a .so file in the top level directory, no need to
make a symlink of it into the top level directory.
- link.od and link-shlib.od forgot to make use of the $xLIBS variable.
* master:
builder.py: atomically replace the log for a given target.
redo-ifchange regression: if REDO_LOG is not set, assume it's 1.
Explicitly reject target/source filenames with newlines in them.
If redo searched all the way up to /default.do, it would run ./default.do instead.
Overridden files were accidentally getting reclassified as static.
Certain redo post-build failures would still mark a target as built.
minimal/do: remove dependency on 'seq' command.
Previously we were truncating the log if it existed. This would cause
redo-log to produce invalid output if you had the following (admittedly
rare) sequence in a single session:
- start building X
- redo-log starts showing the log for X
- finish building X
- redo-log has not finished showing the log for X yet
- start building X again for some reason
- redo-log sees a truncated logfile.
Now, redo-log can finish reading the original file (which no longer has
a filename since it was overwritten) while the new file is being
created.
At some point this got broken during a refactoring. The result was
that redo-ifchange, run from the command line (as opposed to inside a
.do script) would fail to start the log prettifier.
This only happened if the containing project was buggy, ie. you tried
to build a target that has no .do file available anywhere. However, it
resulted in a confusing outcome for that case, where we'd run the wrong
default.do file with the wrong parameters.
Extended an existing test to catch this mistake.
This is relatively harmless, since we treat them *almost* identically,
except that we print a warning for overridden files to remind you that
something fishy is going on.
Add a test for the actual warning message to ensure it is printed. (I
don't like tests for specific warning messages, but it was necessary in
this case.)
If we failed because:
- target dir doesn't exist
- failed to copy from stdout
- failed to rename $3
We would correctly return error 209, but the target would still be
marked as having been built, so redo-ifchange would not try to build it
next time, beause we forgot to call sf.set_failed() in those cases.
minimal/do worked correctly.
Added a test to catch this in the future.
It was kind of ugly to have this kind of special flag directly in
link.od; now we detect whether it's available. This also gives a
project the ability to override the flag in some other way if they
want.
As a result, rc/shlib.rc needs to be included in all.rc.od if you want
to create or link against shared libraries.
While we're here, also add -Wl,-z,origin on platforms where it works.
This is apparently needed for FreeBSD 8.0 at least, and probably other
platforms.
Reported-by: Wayne Scott <wsc9tt@gmail.com>
Instead of running a bunch of separate rc_include statements in the
background, which causes unpredictable ordering of log output and
prevents -j from controlling parallelism, let's do a single
redo-ifchange for all of them (the slow part) followed by sequentially
checking the results (the fast part).
Some older versions of gcc give "all.hpp: linker input file unused
because linking not done" otherwise, because they don't realize files
named *.hpp are headers.
Reported-by: Wayne Scott <wsc9tt@gmail.com>
- Linking shared libraries needs slightly different options.
- We were trying to detect mach_time.h but needed to detect
mach/mach_time.h instead.
While we're here, add a --disable-shared option to ./configure, which
is different from --enable-static. --disable-shared does not build
*new* share libraries, but doesn't pass -static to the linker
(apparently there is no static linking posible on MacOS).
Now we define HAS_POSIX=1 if it works, and to blank otherwise, to be
consistent with other rc scripts, but it doesn't abort if we can't find
timespec.
Meanwhile, slightly clarify the error message in rc.sh.
Reported-by: Nathaniel Filardo <nwfilardo@gmail.com>
CC.rc was the only "mandatory" detection, which was weird and
inconsistent. Instead, make it optional like the others, and have it
set a HAVE_CC variable appropriately (and have CXX.rc work the same
way). Then, add a default.required.rc.od that checks the HAVE_* for
any variable and aborts if it is not available.
This allows us to fix confusing behaviour in allconfig.do, which would
try every compiler on the system, but redo would print a (non-fatal)
error message (and prevent redo-stamp optimization) when CC.rc failed
for any non-working compilers. Now CC.rc just politely reports that it
didn't find a compiler. Then we change all.rc.od to make CC.rc
mandatory.
Reported-by: Nathaniel Filardo <nwfilardo@gmail.com>
More generally, default.func.rc.od wasn't super useful because you
couldn't specify either a header file or library dependencies. Drop it
and make an explicit clock_gettime.rc.od. As a bonus, this also checks
that CLOCK_MONOTONIC exists as expected.
Reported-by: Wayne Scott <wsc9tt@gmail.com>
To test it out, try this:
./do -j10 build
cd docs/cookbook/c
redo -j10 test
It should detect all the compilers on your system and make three
separate builds for each one: normal, debug, and optimized. Then it
tries to run a test program under each one.
If there are windows cross compilers and you also have 'wine'
installed, it'll try running the test program under wine as well.
redoconf currently has no documentation other than the example program.
We'll fix that later.
These files can appear/disappear during a parallel build, which
confuses mkdocs when it tries to refer to them, even though we never
wanted them in the docs anyway.
Reconnect the builder's original stderr file descriptor after the logger has
finished its job.
Fixes that redo could not be run without a controlling terminal.
We upgraded mkdocs earlier to support some useful features (like the
mkdocs-exclude plugin), but that one changes the highlight.js
configuration to include fewer languages by default. Specify the
additional ones we want to include.
Reported-by: @DRMacIver on twitter
If mkdocs is running in parallel, it can get upset if one of these
files exists when it lists the directory, but doesn't exist when it
goes to generate the output. Fundamentally this is a problem in mkdocs
more than in our code, but we might as well avoid it.
Silently recover if REDO_CHEATFDS file descriptors are closed, because
they aren't completely essential and MAKEFLAGS-related warnings already
get printed if all file descriptors have been closed.
If MAKEFLAGS --jobserver-auth flags are closed, improve the error
message so that a) it's a normal error instead of an exception and b)
we link to documentation about why it happens. Also write some more
detailed documentation about what's going on here.
These are often a good idea, but not necessary here and are distracting
to the tutorial, so let's just take them out.
Reported-by: Jeff Stearns <jeff.stearns@gmail.com>
This got... long... and complicated. But I think it's a really good
demonstration of getting redo to do complicated things elegantly. At
least, I hope it is.
We want to use the mkdocs-exclude plugin, which lets us exclude
particular files from the output directory. But plugins aren't
available in the debian-stable version of mkdocs, so ensure that we're
running a sufficiently new version. If we aren't, gracefully just skip
building the documentation.
WSL (Windows Services for Linux) provides a Linux-kernel-compatible ABI
for userspace processes, but the current version doesn't not implement
fcntl() locks at all; it just always returns success. See
https://github.com/Microsoft/WSL/issues/1927.
This causes us three kinds of problem:
1. sqlite3 in WAL mode gives "OperationalError: locking protocol".
1b. Other sqlite3 journal modes also don't work when used by
multiple processes.
2. redo parallelism doesn't work, because we can't prevent the same
target from being build several times simultaneously.
3. "redo-log -f" doesn't work, since it can't tell whether the log
file it's tailing is "done" or not.
To fix#1, we switch the sqlite3 journal back to PERSIST instead of
WAL. We originally changed to WAL in commit 5156feae9d to reduce
deadlocks on MacOS. That was never adequately explained, but PERSIST
still acts weird on MacOS, so we'll only switch to PERSIST when we
detect that locking is definitely broken. Sigh.
To (mostly) fix#2, we disable any -j value > 1 when locking is broken.
This prevents basic forms of parallelism, but doesn't stop you from
re-entrantly starting other instances of redo. To fix that properly,
we need to switch to a different locking mechanism entirely, which is
tough in python. flock() locks probably work, for example, but
python's locks lie and just use fcntl locks for those.
To fix#3, we always force --no-log mode when we find that locking is
broken.
On MacOS (at least 10.11.6), /bin/pwd defaults to using $PWD (ie. pwd
-L). On most other OSes it defaults to *not* using $PWD (ie. pwd -P).
We need the latter behaviour. It appears that 'pwd -P' has been
specified by POSIX for quite a few years now, so let's rely on it.
shelltest.od will now also check for it, though if your 'sh' doesn't
support this feature, it'll be too late, because shelltest needs
minimal/do in order to run.
This is unfixable when running with -j > 1 because of how the current
t/flush-cache script works. We'll only be able to fix that after
making a more granular flush-cache tool, which is already on my todo
list.
This new test validates that you can pass -j1 and -j2 in a sub-redo to
create a sub-jobserver with exactly the number of jobs you specified.
Now that we have that feature, we can also test for the bug fixed two
commits ago where, with -j1, targets would be built in an unexpected
order.
Previously, if you passed a -j option to a redo process in a redo or
make process hierarchy with MAKEFLAGS already set, it would ignore the
-j option and continue using the jobserver provided by the parent.
With this change, we instead initialize a new jobserver with the
desired number of tokens, which is what GNU make does in the same
situation. A typical use case for this is to force serialization of
build steps in a subtree (by using -j1). In make, this is often useful
for "fixing" makefiles that haven't been written correctly for parallel
builds. In redo, that happens much less often, but it's useful at
least in unit tests.
Passing -j1 is relatively harmless (the redo you are starting inherits
a token anyway, so it doesn't create any new tokens). Passing -j > 1
is more risky, because it creates new tokens, thus increasing the level
of parallelism in the system. Because this may not be what you wanted,
we print a warning when you pass -j > 1 to a sub-redo. GNU make gives
a similar warning in this situation.
After waiting for children to exit, we would release our own token, and
then the caller would immediately try to obtain a token again. This
accounted for tokens correctly, but would pass tokens around the call
tree in unexpected ways.
For example, imagine we had only one token. We call 'redo a1 a2', and
a1 calls 'redo b1 b2', and b1 calls 'redo c1'. When c1 exits, it
releases its token, then tries to re-acquire it before exiting. This
also includes 'redo b1 b2' and 'redo a1 a2' in the race for the token,
which means b1 might get suspended while *either* a2 or b2 starts
running.
This never caused a deadlock, even if a2 or b2 depends on b1, because
if they tried to build b1, they would notice it is locked, give up
their token, and wait for the lock. c1 (and then b1) could then obtain
the token and immediately terminate, allowing progress to continue.
But this is not really the way we expect things to happen. "Obviously"
what we want here is a straightforward stack unwinding: c1 should finish,
then b1, then b2, then a1, then b2.
The not-very-obvious symptom of this bug is that redo's unit tests
seemed to run in the wrong order when using -j1 --no-log. (--log would
hide the problem by rearranging logs back into the right order!)
all.do's main job was to print a "nothing much to do" message after
running. Nowadays it actually does do stuff, so we can remove the
warning, making _all.do redundant.
posh will abort the entire script if it detects a syntax error. I
don't know if that's good or not, but you shouldn't be writing scripts
with syntax errors, so that by itself isn't a good reason for posh to
fail.
It still fails some actual tests, but at least now we don't consider it
a 'crash' outcome.
