PPL configuration [--enable-instanciations=c should be default]
Hello All, & specially Roberto.
May I suggest a wish for next versions of PPL: always --enable-interfaces=c at least, and possibly --enable-instanciations=c also (so perhaps make that option obsolete). C++ being conceptually a superset of C, I would believe that every PPL client wants at least a C API. (and on todays computers, getting it is cheap in compilation time).
While I understand that not every PPL user is using Ocaml, I would believe that each PPL user has a C compiler (usually, gcc).
FWIW, GCC MELT (see http://gcc.gnu.or/wiki/MELT for more) needs the ppl_io_asprint_Polyhedron and other ppl_io_asprint_ functions from the C API of PPL), and very strangely, depending upon distributions, even with exactly the same version of PPL, this function is available with some distributions and missing in others (it might be related to the libppl-c-dev package of debian, which seems to have died.?).
Alternatively, autoconf tricks (compatible with the autoconf version used by GCC 4.5.1) to test availability of ppl_io_asprint_Polyhedron are welcome. Don't forget Roberto that I am not as fluent with autoconf as you are!
If you read French, more details are available on http://groups.google.com/group/gcc-melt-french/browse_thread/thread/ae128612... (or you can ask them to me, or better yet, try to build GCC MELT).
Cheers.
Il 11/10/2010 17:46, Basile Starynkevitch ha scritto:
Hello All, & specially Roberto.
May I suggest a wish for next versions of PPL: always --enable-interfaces=c at least, and possibly --enable-instanciations=c also (so perhaps make that option obsolete). C++ being conceptually a superset of C, I would believe that every PPL client wants at least a C API. (and on todays computers, getting it is cheap in compilation time).
Hello Basile.
I may be misunderstanding something in your message ...
Anyway, let me point out that the C interface bindings are enabled by default in the PPL configuration script (I haven't checked old versions though). Therefore, what you report is probably just a packaging problem. Some distributions were insisting on having separate packages for the various language interfaces, so that the packager was explicitly disabling the C interface on the main ppl package. Could that be the real problem?
Also note that there is no option named --enable-instanciations=c There is an option named --enable-instantiations=... but it does not take a language, rather it takes a list of domains that should be enabled in the required interfaces. For instance,
--enable-instantiations=Polyhedron@Grid@BD_Shape<int8_t>
Even in this case the default is quite rich, so that you would normally not need to provide the option explicitly ... but again it could have been overridden by packagers.
While I understand that not every PPL user is using Ocaml, I would believe that each PPL user has a C compiler (usually, gcc).
FWIW, GCC MELT (see http://gcc.gnu.or/wiki/MELT for more) needs the ppl_io_asprint_Polyhedron and other ppl_io_asprint_ functions from the C API of PPL), and very strangely, depending upon distributions, even with exactly the same version of PPL, this function is available with some distributions and missing in others (it might be related to the libppl-c-dev package of debian, which seems to have died.?).
This really sounds strange ... we will have a look into it.
Cheers, Enea.
Alternatively, autoconf tricks (compatible with the autoconf version used by GCC 4.5.1) to test availability of ppl_io_asprint_Polyhedron are welcome. Don't forget Roberto that I am not as fluent with autoconf as you are!
If you read French, more details are available on http://groups.google.com/group/gcc-melt-french/browse_thread/thread/ae128612... (or you can ask them to me, or better yet, try to build GCC MELT).
Cheers.
participants (2)
-
Basile Starynkevitch -
Enea Zaffanella