Configure substitutions are not allowed in _SOURCES variables

Hi there,
I desperately need a way out this limitation of Automake.
The problem is as follows: the Parma Polyhedra Library (http://www.cs.unipr.it/ppl/) provides foreign interfaces (C, OCaml, Prolog and Java) to a number of abstract domains. The abstract domains that are interfaced are selectable at configure time, and can be (literally) hundreds. The C++ code for the interfaces is automatically generated and we used to put it all in one file. However, this poses serious problems as the compilation of that (possibly gigantic) file easily causes GCC to consume gigabytes of main memory. We have now modified the generator so as to generate one C++ source per domain; we would like to compile all these files separately and and to put all the corresponding objects into a library.
Using the solution outlined in the Automake manual (i.e., using conditionals) would cause us to write enormous Makefile.am files which would be a maintenance nightmare. That is, now everything is automated; if we use a long chain of conditionals we would have to maintain consistency by hand.
Is there any other possibility? All the best,
Roberto

Hello Roberto,
* Roberto Bagnara wrote on Thu, Aug 21, 2008 at 12:55:25PM CEST:
[ ... lots of sources, conditional and all ... ]
Using the solution outlined in the Automake manual (i.e., using conditionals) would cause us to write enormous Makefile.am files which would be a maintenance nightmare. That is, now everything is automated; if we use a long chain of conditionals we would have to maintain consistency by hand.
Are you saying that you generate Makefile.am (or an include snippet for it) automatically? If not, why not, if yes, what is the problem with maintaining consistency with a script? Ideally, you generate both the files and the makefile.am snippet from the same script.
Do you already do the splitup in CVS? I cannot see it there (I just got HEAD from :pserver:anoncvs@cvs.cs.unipr.it:/cvs/ppl).
Cheers, Ralf

Ralf Wildenhues wrote:
- Roberto Bagnara wrote on Thu, Aug 21, 2008 at 12:55:25PM CEST:
[ ... lots of sources, conditional and all ... ]
Using the solution outlined in the Automake manual (i.e., using conditionals) would cause us to write enormous Makefile.am files which would be a maintenance nightmare. That is, now everything is automated; if we use a long chain of conditionals we would have to maintain consistency by hand.
Are you saying that you generate Makefile.am (or an include snippet for it) automatically?
Hi Ralf,
no. In the previous version we generated automatically the individual C++ sources, including one that #included all the others. The list of C++ sources is only known at configure time: at that time the sources are generated.
If not, why not, if yes, what is the problem with maintaining consistency with a script? Ideally, you generate both the files and the makefile.am snippet from the same script.
Can I generated the Makefile.am at configure time? Notice that the list of domains is really unbounded: the PPL supports constructions on domains like products and powersets. So the user can ask for a product of a powerset of a product of ... We really cannot anticipate all the possibilities.
Do you already do the splitup in CVS? I cannot see it there (I just got HEAD from :pserver:anoncvs@cvs.cs.unipr.it:/cvs/ppl).
I am halfway through it. I thought I had found a workaround, but there are still problems. What I have at the moment is something that suffers from the problem outlined above and, in addition, does not work:
pkglib_LTLIBRARIES = libppl_swiprolog.la
nodist_libppl_swiprolog_la_SOURCES = \ ppl_swiprolog.cc
EXTRA_libppl_swiprolog_la_SOURCES = \ ../ppl_prolog_Polyhedron.cc \ ../ppl_prolog_Grid.cc \ ../ppl_prolog_Pointset_Powerset_C_Polyhedron.cc \ ../ppl_prolog_Pointset_Powerset_NNC_Polyhedron.cc # The above is the list of configure-dependent sources # that we cannot anticipate. So listing the files here # is unsatisfactory.
libppl_swiprolog_la_LIBADD = \ @required_instantiations_prolog_cxx_objects@ \ $(top_builddir)/src/libppl.la \ $(WATCHDOG_LIBRARY) \ @extra_libraries@
# @required_instantiations_prolog_cxx_objects@ contains # the list of the .lo file corresponding to the .cc files # above. If I do `make libppl_swiprolog.la' I get # the error that the (inexistent) .lo files are invalid # Libtool files. Bot if I do, e.g., # `make pl_prolog_Polyhedron.lo' the right thing happens. # I wonder why `make libppl_swiprolog.la' does not make # all the required .lo files.
Thanks,
Roberto

* Roberto Bagnara wrote on Thu, Aug 21, 2008 at 08:00:04PM CEST:
Ralf Wildenhues wrote:
Are you saying that you generate Makefile.am (or an include snippet for it) automatically?
no. In the previous version we generated automatically the individual C++ sources, including one that #included all the others. The list of C++ sources is only known at configure time: at that time the sources are generated.
Well, as long as the list of possible source can be enumerated, you can use EXTRA_*_SOURCES to list them.
If not, why not, if yes, what is the problem with maintaining consistency with a script? Ideally, you generate both the files and the makefile.am snippet from the same script.
Can I generated the Makefile.am at configure time?
No.
Notice that the list of domains is really unbounded: the PPL supports constructions on domains like products and powersets. So the user can ask for a product of a powerset of a product of ... We really cannot anticipate all the possibilities.
That's a problem.
There *may* be a workaround. Let's rather call it ugliest hack ever. It *requires* that you don't use per-target flags. It does not provide dependency tracking for the generated files.
I am halfway through it. I thought I had found a workaround, but there are still problems. What I have at the moment is something that suffers from the problem outlined above and, in addition, does not work:
[...]
# @required_instantiations_prolog_cxx_objects@ contains # the list of the .lo file corresponding to the .cc files # above. If I do `make libppl_swiprolog.la' I get # the error that the (inexistent) .lo files are invalid # Libtool files. Bot if I do, e.g., # `make pl_prolog_Polyhedron.lo' the right thing happens. # I wonder why `make libppl_swiprolog.la' does not make # all the required .lo files.
Yep. Your approach is essentially the hack I had in mind. Put the added objects in libppl_swiprolog_la_DEPENDENCIES, too, then things will work. Of course then you have to put everything else manually in that DEPENDENCIES variable, too (which automake would otherwise do).
Cheers, Ralf

Ralf Wildenhues wrote:
Yep. Your approach is essentially the hack I had in mind. Put the added objects in libppl_swiprolog_la_DEPENDENCIES, too, then things will work. Of course then you have to put everything else manually in that DEPENDENCIES variable, too (which automake would otherwise do).
Thanks a lot Ralf. I am not trying to complete that into something working. If you don't mind, I will let you know when I am done so that you can take a look. Cheers,
Roberto
participants (2)
-
Ralf Wildenhues
-
Roberto Bagnara