[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