Automake compatibility issues of ports using the GNU build system #4350
Labels
Comments
nfeske
added a commit
that referenced
this issue
Dec 16, 2021
This patch discharges the dependency of Makefile.in from Makefile.am files whenever both files are present in a downloaded archive. Being based on make, the trigger of running automake is based on the timestamps for the extracted archive content. However, since we reset the timestamps (via 'tar -m') at extraction time, no assumptions about the timestamp relations between the extracted files can be made. In the event automake is triggered, we are faced with the tool dependency from a specific automake version on the host. The patch enforces the unconditional use the 'Makefile.in' version supplied by the archive. Fixes #4350
|
Commit 633c17d addresses this issue by discharging the offending make rule when preparing a port. The solution is arguably not nice but all alternative band-aids I can think of would be even worse. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We sporadically encounter the issue that a port requires a specific automake version to be installed on the host. Sometimes, the correct version is not readily available from the official distro repositories. In most cases, the invocation of automake is actually superfluous because the downloaded 3rd-party code comes with a generated Makefile.in. But in the event the timestamp of the .in file is older than the timestamp of the Makefile.am file, a make rule kicks in that tries to update the .in file.
The behavior depends on the extraction order of files from the 3rd-party archive. With the change of #4262, this order can be arbitrary. Even though we already observed the problem sporadically in the past (depending on the circumstances how the 3rd-party archive was created), it became more prominent recently.
The text was updated successfully, but these errors were encountered: