<div dir="ltr">My experience of libxml2 has been favourable. I'm happy with a dependency on it, but someone needs to identify a version (preferably one that is known to be in package repos and/or have binaries available on the web). I would suggest we implement the dependency roughly as we do for FFTW:<div>
<br></div><div>* the install guide drops suitable hints to go get libxml2-dev(el) from your favourite repo (note that libxml2 might be installed by default, but we might need the #include headers that are only in the -dev or -devel packages!)</div>
<div>* CMake detects if those exist in CMAKE_PREFIX_PATH, and gives a fatal error if not found.</div><div>* the fatal error can be avoided by either letting the user supply a libxml2 tarball (e.g. so we can test in Jenkins also), or use cmake -DGMX_BUILD_OWN_LIBXML2 to do the same download-and-build thing.</div>
<div><br></div><div>Even if legal, I'm not so keen on bundling the libxml2 tarball at ~5MB, when gromacs is ~10MB. Bundling just the headers we need in order to use a system libxml2 might be a good option.</div><div><br>
</div><div>The proposed bump to require CMake version 2.8.8 in Redmine/Gerrit should make this a little smoother than it has been in the past.</div><div><br></div><div>I think there should be a wrapper layer between libxml2 and the GROMACS code that uses it, so that we have the option to change the implementation if we want to do so later.</div>
<div><br></div><div>There was an interesting post from Marcus Hanwell from Kitware on this list earlier this year about how their projects handle this kind of thing, (<a href="http://gromacs.5086.x6.nabble.com/parallel-make-problems-td5009226.html">http://gromacs.5086.x6.nabble.com/parallel-make-problems-td5009226.html</a>) which seems like it should be what we should do now that we have several of these kinds of dependencies currently "living" in src/external (FFTW, Boost subset, TNG, now libxml2, maybe later PDBx or some FMM code, maybe gmxblas and gmxlapack should go live there). For 5.0, I can live with a hack that copies how we handle FFTW, though.</div>
<div><br></div><div>Mark</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Nov 10, 2013 at 9:35 PM, David van der Spoel <span dir="ltr"><<a href="mailto:spoel@xray.bmc.uu.se" target="_blank">spoel@xray.bmc.uu.se</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 2013-11-10 20:58, Erik Lindahl wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
One reason could be that we haven’t really started to use standardized XML input/output formats yet, although we’re heading there long term. I’m also not enough of an expert to say whether libxml2 is the best XML parser out there, since there are quite a few alternatives?<br>
<br>
If there are any specific new modules that would need it, doesn’t it make more sense to have those modules go through the normal code review (including a discussion of whether the proposed XML formats are nicely designed, etc), rather than separately making XML a hard requirement even if the current code doesn’t rely on it?<br>
<br>
</blockquote></div>
This is why I asked. I think we should refrain from adding more text only poorly documented files that are prone to errors. Therefore I used a XML files in this patch <a href="https://gerrit.gromacs.org/#/c/2659/" target="_blank">https://gerrit.gromacs.org/#/<u></u>c/2659/</a>, however Teemu pointed out that it does not compile without XML (since there are no ifdefs). So rather than implementing TWO versions of the code to read in the necessary data, we have to decide to make this obligatory now or not.<br>
<br>
As regards compiling under windows (from the libxml2 website):<br>
<br>
Libxml2 is known to be very portable, the library should build and work without serious troubles on a variety of systems (Linux, Unix, Windows, CygWin, MacOS, MacOS X, RISC Os, OS/2, VMS, QNX, MVS, VxWorks, ...)<br>
<br>
It is distributed under the MIT license so I guess we could even include it in the source code as a backup. With the known portability and the license I don't see any reason not to. It comes pre-installed on Macs and Linux by the way.<div class="HOEnZb">
<div class="h5"><br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
<br>
Erik<br>
<br>
On 10 Nov 2013, at 11:51, David van der Spoel <<a href="mailto:spoel@xray.bmc.uu.se" target="_blank">spoel@xray.bmc.uu.se</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
we have decided a long time ago that for 5.0 libxml2 would be required.<br>
If there is any reason why we should remain to be able to compile<br>
gromacs WITHOUT libxml2, please speak up now.<br>
<br>
If no good arguments will be brought forward then I will change the main<br>
CMakeList.txt such that gromacs will not compile without it.<br>
<br>
--<br>
David van der Spoel, Ph.D., Professor of Biology<br>
Dept. of Cell & Molec. Biol., Uppsala University.<br>
Box 596, 75124 Uppsala, Sweden. Phone: <a href="tel:%2B46184714205" value="+46184714205" target="_blank">+46184714205</a>.<br>
<a href="mailto:spoel@xray.bmc.uu.se" target="_blank">spoel@xray.bmc.uu.se</a> <a href="http://folding.bmc.uu.se" target="_blank">http://folding.bmc.uu.se</a><br>
--<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/<u></u>mailman/listinfo/gmx-<u></u>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@<u></u>gromacs.org</a>.<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
-- <br>
David van der Spoel, Ph.D., Professor of Biology<br>
Dept. of Cell & Molec. Biol., Uppsala University.<br>
Box 596, 75124 Uppsala, Sweden. Phone: <a href="tel:%2B46184714205" value="+46184714205" target="_blank">+46184714205</a>.<br>
<a href="mailto:spoel@xray.bmc.uu.se" target="_blank">spoel@xray.bmc.uu.se</a> <a href="http://folding.bmc.uu.se" target="_blank">http://folding.bmc.uu.se</a><br>
-- <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/<u></u>mailman/listinfo/gmx-<u></u>developers</a><br>
Please don't post (un)subscribe requests to the list. Use the www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@<u></u>gromacs.org</a>.<br>
</div></div></blockquote></div><br></div>