[gmx-developers] manpage generation brakes build process
Szilárd Páll
szilard.pall at cbr.su.se
Thu Aug 30 15:03:53 CEST 2012
Hi,
Commit 26bd5f7 made the build process generate man pages and broke
compilation for the most common cross-compile builds: when the build
host doesn't support the instruction set of the target, e.g. a
cluster's head node with "older" CPUs than the cluster nodes. To me it
seems that the CMAKE_CROSSCOMPILING variable used to implement the
detection of cross-compilation is pretty much useless because
apparently it takes into account only the CMAKE_SYSTEM_NAME. This only
detects when one builds e.g Windows binaries on Linux, but nothing
else.
The annoying part is that the build process fails a cryptic "error
132" after linking the binary and the user won't have a clue what's
wrong.
In my opinion by default automatically generating man pages is not
very important because:
- source releases can contain the man pages;
- the development versions are either:
- in pre-release stage when one wouldn't rely on the man pages being
very up-to-date anyway;
- post-release stage when there should not be many major changes
compared to the latest patch release.
I would suggest that we stick to installing static in-source man pages
by default and we can provide a switch to generate them during
building. It is fairly complicated to detect whether the binaries
built will run on the host, so I think it is not worth writing such
code that is error-prone and hard to maintain.
Does anybody have a better idea to fix this issue?
--
Szilárd
More information about the gromacs.org_gmx-developers
mailing list