[vsipl++] PATCH: installation / packaging

[Stefan Seefeld]

Jules Bergmann wrote:

> IIUC, the DESTDIR is prepended to the different directories objdir, 
> libdir, etc.  I think this is the right thing to do, because it lets 
> build a binary package to live in an arbitrary system directory 
> (/opt/csl/vsipl++) without having to have modify that directory on our 
> build machine.

Precisely. It allows an installation into a fake (virtual) root that
then only contains the newly installed bits, so tar will not pick up
any undesired pieces.

> However, there might be a problem when trying to build one copy of the 
> ATLAS/FFTW libraries to be used by all variants.  Consider:
> 
> # first, build optimized version of VSIPL++, ATLAS, and FFTW
> prefix=/opt/vsipl++
> configure "opt-flags" --with-fft=builtin --with-lapack=builtin 
> --prefix=$prefix
> make
> make doc maintainer_mode=1
> make install DESTDIR=tmp suffix=-opt
> 
> # second, build debug version of VSIPL++,
> # Don't build ATLAS and FFTW again, instead use the versions already in 
> /opt/vsipl++
> LDFLAGS="-L$prefix/lib"
> CPPFLAGS="-L$prefix/include"
> configure "debug-flags" --with-fft=fftw3 -with-lapack=atlas
> make
> make install DESTDIR=tmp suffix=-debug
> 
> ... make other variants ...
> ... create alias (vsipl++.pc -> vsipl++-opt.pc)
> ... make binary package ...
> 
> 
> When configuring for the debug build, the libraries for ATLAS and FFTW 
> will not be found, since they are in /tmp/opt/vsipl++, not 
> /opt/vsipl++.  Also, when making the debug library, the headers will not 
> be in the right spot either.

That's right. In fact, we touched that subject when discussing the suffix
option previously. Being able to package all variants into a single prefix,
and sharing the same set of headers, imposes some constraints on how much
the different configurations can actually differ.
I think we were discussing the suffix flag in the context of differing
compilation flags (e.g. -g vs. -O3), but not e.g. using IPP vs. ATLAS.

Such differences will probably have to be installed in distinct prefixes
for a number of reasons, for example because the generated config header
isn't the same.

> A work around is to build the ATLAS and FFTW libraries for each variant 
> (optimized, debug, etc), rely on them to be overwritten so that only one 
> copy of those libraries are in the final package,  and make sure to 
> build the version of the external libraries that we want to keep last.  
> However, if we have many variants, this will result in a lot of time 
> spent building ATLAS.

I haven't looked into the vendor package compilation, but my impression
was that we now have no way to distinguish different configurations
at link time. Am I wrong ? The only configurations that can coexist
are one configuration without and one with ATLAS (say). However, there
is still the acconfig.hpp issue I mentioned above...

> Another idea is to have ATLAS and FFTW installed on our build system so 
> that the bogus paths are not noticed by configure/make.  However this 
> makes the build process a little less robust.

Indeed. I think we should make sure the compilation is as isolated as
possible, and thus can be reproduced anywhere without reliance on external
resources that aren't explicitely described in the documentation.

> A final idea is to tell configure to trust that fftw3 and atlas are 
> present and not test for them.  ("--with-fft=trust-fftw3" ?).  We would 
> also need to handle the include paths during the make (via INT_CPPFLAGS?)
> 
> Any thoughts on how to handle this?

I really doubt the suffix-only approach is able to deal with multiple
vendor library versions. We really need different prefixes for that.

>> Mark, doc/csl-docbook/GNUmakefile.inc contains two changes:
>>
>> * I prefixed all installation paths with $(DESTDIR) to make the above
>>   work for documentation.
>> * I fixed the %.html target for the case where $(docbook_html) is not 
>> set,
>>   as that case seems to have slipped through in Carlos' latest 
>> adjustments.
> 
> 
> Is there an email list that we should send csl-docbook CVS changes to?

I had planned to send the changelog to gnu-internal.

Regards,
		Stefan