(More) Compilation & Configuration Errors

[JoaoRodrigues]

Another little issue, this time related to building the documentation. Working on a clean up-to-date master branch:

$ autoreconf
$ ./configure
LaTeX not available, .dvi and .ps documentation cannot be built
./configure: line 5212: .pdf: command not found
Doxygen not available, html documentation cannot be built

$ make
/Library/Developer/CommandLineTools/usr/bin/make  all-recursive
Making all in doc
Making all in fig
make[3]: Nothing to be done for `all'.
make[3]: *** No rule to make target `fig/lnr_circles.eps', needed by `all-am'.  Stop.
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I also have a suggestion: if possible, it would be great to be able to build only the executable and not the documentation and test suite, either through --without-doc / --without-tests flags, or make commands (e.g. make all; make doc; make src), or whatever else is smarter and more appropriate here.

p.s. sorry for all the issues ;)

[mittinatten]

Yes, I have been fiddling with this too the last few days, I have tried to find a system to push the Doxygen output to the GitHub-pages, hope I haven't broken anything in the process (I at least always make sure make distcheck works before I push to master). Having Doxygen available online makes it even less necessary to make that part of the standard build. Also compiling the latex and doxygen parts takes a lot longer than compiling the source, which is kind of stupid.

I think excluding 'doc' from the 'all' target makes sense. Maybe --enable-tests and --enable-docs are even more sensible: that would make the standard build essentially dependency-free. As I said I am not very experienced with configuring automake and autoconf, but will try to figure this out.

No need to be sorry, it's great to get some real-life input. Lots of these issues are linked to exact machine setup and I have only been testing on two different setups so far (Debian and Mac) so it's great to see what can happen outside that limited setup.

[JoaoRodrigues]

It's easy to solve on the short-term (just comment the doc part on the makefile), so take your time, the gh-pages look great.

As an aside, autoconf, automake, and pkg-config still remain dependencies to build, which is not necessarily simple to install on a Mac for example (for a regular user I mean). The pkg-config dependency in particular is a pain because it actually reports as failing to meet the CHECK requirement. Read here and here for some alternatives and specific insight on this issue.

[mittinatten]

Think I solved the Check, LaTeX and Doxygen dependencies now. New options to the configure-script are --enable-check, --enable-latex and --enable-doxygen.

The autotools dependencies could be fixed by including the automatically generated scripts and .in-files in the repo, which I guess wouldn't be a big deal, although not elegant.

[mittinatten]

I think I will see if I can provide make dist tarballs through the download page instead, these will not be autotools-dependent. From what I have read, keeping the generated files under version control can be a hassle.

[JoaoRodrigues]

:+1: Cool, I'll give it a try then.

I made a sort of dependency-free branch on my fork to avoid these dependencies, but that was just from running autoreconf on my machine and editing the makefiles to avoid the compilation issues. Works in both Mac and Linux (without autoconf, automake, etc) so far. But something more "automated" is better.

The tarballs should definitely be autotools-free, I guess users won't be happy to have to download the entire build tools :) In plenty of cases of libraries, the git repo cloning requires building while the tarballs have the configure-make-etc toolchain already.

[mittinatten]

With the latest release I have started uploading make dist-tarballs to the web. Available here

https://github.com/mittinatten/freesasa/releases/tag/0.3.0

and here

http://mittinatten.github.io/freesasa/