slayoo
commented
5 years ago Open slayoo opened 6 years ago
slayoo
commented
5 years ago slayoo
commented
5 years ago Posting here relevant comments from the mailing list:
Julian Cummings on 2012-08-29:
... question you are asking is whether the compiler version should then be included as part of the install path for the config.h header. It is conceivable that we could do this, although the typical user probably does not have multiple compiler versions and packages built with each version installed on their machine. For the purposes of testing a new compiler version, this can be addressed by selecting a different $prefix for the trial installation.
... I am not so familiar with the clang compiler system. Shouldn't this one already be identified as distinct from the gnu compiler? If so, the compiler options portion of the blitz configure script should be updated to detect this and place the config.h file in $prefix/include/blitz/clang.
@sergiopasra on 2012-09-04:
There is another problem regarding these file, related with 32 bits vs 64 bits architectures.
Let me explain the problem a little bit. (Disclaimer: I'm the Fedora packager of blitz)
Fedora provides RPM (precompilled binary) packages of blitz, header and libraries are in different packages, in this case blitz.rpm and blitz-devel.rpm. RPM can be compilled for a given architecture (x86_64 vs i686 in current Fedora) or it can be architecture independent (noarch). Most -devel RPMs contain only headers and are noarch. Blitz contains this file gnu/bzconfig.h which depends on the architecture, so there are two packages: blitz-devel.i686.rpm blitz-devel.x86_64.rpm
An here comes the problem. Packages must be parallel installable. In a x86_64 system we can have both blitz-devel.i686.rpm and blitz-devel.x86_64 The contents of these packages are identical (they are headers and documentation) except this file gnu/bzconfig.h
The solution I have found to comply with the multilib policy of Fedora is to move this file to an arch dependent directory (/usr/lib{,64}/blitz/include/blitz) and modify blitz.pc to add the directory to the include path with -I, so that using pkg-config you are save.
@slayoo (i.e., myself) on 2012-09-07:
Debian's blitz/config.h contains for instance:
25 / define if the Boost library is available / 26 / #undef HAVE_BOOST / 27 28 / Define to 1 if you have the <boost/mpi.hpp> header file. / 29 / #undef HAVE_BOOST_MPI_HPP / 30 31 / define if the Boost::Serialization library is available / 32 / #undef HAVE_BOOST_SERIALIZATION /
259 / Enable Blitz thread-safety features / 260 / #undef THREADSAFE /
which, if I understand correctly, correspond to configure-time options. However, since Blitz is de facto header-only, are these values more "defaults" than hard-coded settings - is it enough to define HAVE_BOOST before including Blitz? Something alike is mentioned in the docs concerning #define BZ_THREADSAFE.
Patrik Jonsson on 2012-0907:
These defines determine whether certain features are included. I guess you could call them "defaults" in the sense that there is no compiled-in code (except libblitz, which I don't think is affected by any) that depends on them. So if you defined these macros in your code, and made sure to do before including any blitz file and in every file that included blitz, it would probably work. It is error prone, though, because you make a mistake so different compilation units in your code have different blitz options, this will almost certainly result in a subtle segfault. Also, you would not be able to undo a macro that is defined (as opposed to not defined) in the blitz headers, since it would be defined and then read by the blitz headers without you having an opportunity to change it.
The alternative would be to remove all these config options and require the users to specify them, but that puts a large burden on the users knowing more about the blitz innards than they probably want...
Packaged versions of Blitz are shipped with bzconfig.h file full of information on the compiler features and library availability which not necessarily match the ones of the environment in which package users are working. Is there any way we could help packagers resolve this issue?