#987 build system: do not force all modules to place their headers in $DUNE_MODULE_ROOT/dune/
Metadata
| Property | Value |
|---|---|
| Reported by | Andreas Lauser (andreas.lauser@iws.uni-stuttgart.de) |
| Reported at | Dec 5, 2011 18:23 |
| Type | Bug Report |
| Version | 2.1 |
| Operating System | Linux |
| Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Last edited at | Jun 21, 2012 09:58 |
| Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Closed at | Jun 21, 2012 09:58 |
| Closed in version | Unknown |
| Resolution | Not a bug |
| Comment |
Description
Dumux currently places all headers in $DUNE_MODULE_ROOT/dumux/. Since the DUNE_CHECK_MODULES expects all headers to be placed in the module's 'dune/' subdirectory, the current solution used by Dumux is to completely replace the DUNE_CHECK_MODULES autoconf macro with a custom version. Since, IMHO, this is a pretty bad hack, it would be nice if the DUNE build system would not force all modules to be called 'dune-$FOO'. The attached patch does just this.
In order to not having to change existing dune-$FOO.m4 files, the patch first looks whether the path given as an argument to DUNE_CHECK_MODULES is relative to the $MODULE_ROOT/dune directory (which is the current behavior), if the header is not found there, it checks whether the path is relative to $MODULE_ROOT.
N.B. this patch is for the 2.1 branch, use it at your own risk for trunk. It would be great if it could be also included in the 2.1 branch as it would allow us at IWS to drop the currently used hack for our next release.