Welcome to the Bug Tracking System for the DUNE project.
Due to increasing spam attacks, we had to disable the feature of anonymous bug reports. You will have to register before you are able to report a new bug.
In case you experience any problems, let us know at http://www.dune-project.org/mailinglists.html .
Tasklist

FS#230 - configure should support 'private' modules

Attached to Project: Dune
Opened by Christian Engwer (christi) - Thursday, 04 January 2007, 20:53 GMT+2
Last edited by Christian Engwer (christi) - Thursday, 08 April 2010, 22:30 GMT+2
Task Type Feature Request
Category Infrastructure → Build-System
Status Closed
Assigned To Christian Engwer (christi)
Operating System Unspecified / All
Severity High
Priority Urgent
Reported Version SVN (pre2.1)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

In order to test for a module during configure, this module must be mentioned in dune-common/m4/dune.m4.

This will not hold for long. When the fist 'private' modules occure this must be changed.

Necessary steps:

1) generate full dependencies during autoconf
2) read direct dependencies and from dune.module file
3) allow per module m4-files
4) update autogen.sh
5) update duneproject
Closed by  Christian Engwer (christi)
Thursday, 08 April 2010, 22:30 GMT+2
Reason for closing:  Implemented
Comment by Christian Engwer (christi) - Sunday, 06 January 2008, 13:16 GMT+2
The first step is done. autoconf can automatically generate the dependecies from the dunecontrol output.
Comment by Christian Engwer (christi) - Monday, 07 January 2008, 17:14 GMT+2
full dependencies are generated from dune.module file
Comment by Markus Blatt (mblatt) - Wednesday, 16 January 2008, 10:45 GMT+2
The module name is not resolved in the makefiles:

In all make files there is

pkgdatadir = $(datadir)/dune_mod_name
pkglibdir = $(libdir)/dune_mod_name
pkgincludedir = $(includedir)/dune_mod_name
Comment by Christian Engwer (christi) - Tuesday, 04 March 2008, 17:47 GMT+2
Mental note...

During our discussion on the developer meeting I suggested to dynamically create one dune.m4 and the use this m4 to create configure and so one. This could help avoid problems with unresolved m4 dependencies. Right now this does not work, because the dependencies are determined dynamically and therefore some files might not be included into aclocal.m4 .
Comment by Christian Engwer (christi) - Thursday, 08 May 2008, 13:52 GMT+2
There are certain problems with this approach. I suggest to radically change the code.

We could create m4 files during autogen which contain the results currently obtained from all the m4-dune.module-parsing stuff.

Find a suggested patch attached.

Please comment on this!
   common.diff (5.6 KiB)
Comment by Christian Engwer (christi) - Tuesday, 20 May 2008, 23:45 GMT+2
In order to allow per module 'am' snipplets, we could use the AC_SUBST_FILE mechanism.

see http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_83.html

Each module could now define new @FOOBAR@ substitutions, referring to a files MODULE_ROOT/am/foobar.am

We could even provide an m4-command which defines these substitutions.
Comment by Christian Engwer (christi) - Wednesday, 18 June 2008, 14:58 GMT+2
I did some tests and AC_SUBST_FILE is able to replace the am include with one small exception.

What works is:

AC_SUBST_FILE get's executed before the other substitutions, that means that we can still use @FOO@ substitution variables in these snipplets.

What does not work is:

All automake magic (if and include) do not work.
- include is not such a big deal, as we can use the substitutions instead
- if can be evaluated by a sed script. We would have to write an am/foo.ax file and transform this to am/foo using the sed script.

Any other ideas?
   ax.sed (0.5 KiB)
Comment by Christian Engwer (christi) - Thursday, 08 April 2010, 22:30 GMT+2
I decided that up to now, we are happy without the possibility to add am-snippets per module. I'll drop this feature and close the task.

Loading...