fix(build): Ship blank lua_modules install list in source packges #969
Conversation
alerque
added
bug
|
Right problem, not quite fixed yet... |
|
So this PR passing tests is a problem. It shows we aren't testing everything we need to be testing. We're building and testing from source, but we're not testing the source package we build for buildability. Automake has |
alerque
force-pushed
the
make-foo
branch
3 times, most recently
from
abf4775
to
6481ed7
Compare
|
Never mind the remote test runs, my local directories are starting to look like this (this is after blowing them away many times):
Automake behaves so differently between versions and platforms its making my head spin. I can hack it to work, but playing by its rulebook is a lot harder and I'm not convinced it can even work the way I want it too. Bah. |
alerque
force-pushed
the
make-foo
branch
2 times, most recently
from
794e1da
to
f90b354
Compare
If for some reason Makefile.in is older than acloacl.a4 and other automake generated files, it will want to regenerate it ... which requires automake tools, and specifically wants matching versions. This simple action (after we're done mucking around with the other files to remove automake's handling of "core") keeps it from thinking it needs to rebuild anything.
Usually this is the same as $(docdir), but it does allow it to be defined separately.
alerque
force-pushed
the
make-foo
branch
6 times, most recently
from
77ae9a6
to
1037493
Compare
alerque
force-pushed
the
make-foo
branch
2 times, most recently
from
dfac500
to
481cd50
Compare
we have a bug somewhere either in automake itself or in our dependencies getting from zero to dist. It works on 1.16.2, but in Docker with 1.16.1 it fails. The two options are either to drop the -j arg and run a single thread or make before make dist. The latter being faster and also more granular in the output, that's what we're up to.
Closes #968.
...Is the actual fix for #961.
...Has been underlying various issues we've had for a long time, but was made a lot more obvious by the refactor done in #965 for #964 because the data that needed to be cleared was previously mixed in with another list of files that was otherwise valid.
...Started turning up in more scenarios because of the work in #953 to fix #951. This was the right thing to do, but our previous hackery before was keeping the problem from showing up by (accidentally) make reruns where the second pass was fixing what the first one broke. Cleaning that up just make the underlying problem surface in more places.