Hi,<div><br></div><div><br><br><div class="gmail_quote">On Thu, Aug 30, 2012 at 9:03 AM, Szilárd Páll <span dir="ltr"><<a href="mailto:szilard.pall@cbr.su.se" target="_blank">szilard.pall@cbr.su.se</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
Commit 26bd5f7 made the build process generate man pages and broke<br>
compilation for the most common cross-compile builds: when the build<br>
host doesn't support the instruction set of the target, e.g. a<br>
cluster's head node with "older" CPUs than the cluster nodes. To me it<br>
seems that the CMAKE_CROSSCOMPILING variable used to implement the<br>
detection of cross-compilation is pretty much useless because<br>
apparently it takes into account only the CMAKE_SYSTEM_NAME. This only<br>
detects when one builds e.g Windows binaries on Linux, but nothing<br>
else.<br>
<br>
The annoying part is that the build process fails a cryptic "error<br>
132" after linking the binary and the user won't have a clue what's<br>
wrong.<br>
<br>
In my opinion by default automatically generating man pages is not<br>
very important because:<br>
- source releases can contain the man pages;<br></blockquote><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- the development versions are either:<br>
- in pre-release stage when one wouldn't rely on the man pages being<br>
very up-to-date anyway;<br>
- post-release stage when there should not be many major changes<br>
compared to the latest patch release.<br>
<br>
I would suggest that we stick to installing static in-source man pages<br>
by default and we can provide a switch to generate them during<br>
building. It is fairly complicated to detect whether the binaries<br>
built will run on the host,</blockquote><div>why? It is as simple as running a binary and see whether it worked, isn't it?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
so I think it is not worth writing such<br>
code that is error-prone and hard to maintain.<br>
<br>
Does anybody have a better idea to fix this issue?</blockquote><div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div> </div>
<div> Roland</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--<br>
Szilárd<br>
<span><font color="#888888">--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
<br>
<br>
<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">cmb.ornl.gov</a><br><a href="tel:865-241-1537" value="+18652411537" target="_blank">865-241-1537</a>, ORNL PO BOX 2008 MS6309<br>
</div>