[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PPL-devel] Configure substitutions are not allowed in _SOURCES vari
Re: [PPL-devel] Configure substitutions are not allowed in _SOURCES variables
Thu, 21 Aug 2008 21:03:17 +0200
* 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?
> 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).