[gmx-developers] manpage generation brakes build process

[Roland Schulz]

Hi,



On Thu, Aug 30, 2012 at 9:03 AM, Szilárd Páll <szilard.pall at cbr.su.se>wrote:

> 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;
>
This is already so. Cpack automatically adds the build man pages and the
man pages are only build if they aren't in the source package. So this is a
non-issue for users which download the source as a source package instead
from git.


> - 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,

why? It is as simple as running a binary and see whether it worked, isn't
it?


> 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?

I prefer if it is done automatically because that makes sure it is
maintained. I think we should have as little as possible of things we do in
the last second before a release (and thus delaying the release) to be able
to release more frequently.

I think it is OK as it is. Because disabling the build is as easy
as GMX_BUILD_MANPAGES=no, and only effects developers and not users. But if
you want me to add a check whether executing binaries is possible, I can do
that.

admin/.isreposource is not specific for github. It is for any download
which is not using git to download source which didn't go through cpack.

 Roland


> --
> Szilárd
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
>
>
>
>
>


-- 
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20120830/86150ff6/attachment.html>