<div dir="ltr"><div>Isnt the Parmetis - Metis dependency handled by the fact, that PARMETIS_LIBRARIES is set to "${PARMETIS_LIBRARY};${METIS_LIBRARY}"? This way, the parmetis library always appears before the metis library. This can be generalized as a rule: If a library depends on other external libraries, it has to enforce the order of the libs on the list of needed libraries before appending that list to ALL_PKG_LIBS.<br><br></div>Dominic<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 16, 2014 at 8:19 PM, Markus Blatt <span dir="ltr"><<a href="mailto:markus@dr-blatt.de" target="_blank">markus@dr-blatt.de</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Dec 16, 2014 at 07:32:18PM +0100, Dominic Kempf wrote:<br>
> we did not add the DUNE_LIBS to the ALL_PKG_LIBS, but wrote the macro<br>
> add_dune_all_flags in a way, that it appends both DUNE_LIBS and<br>
> ALL_PKG_LIBS (in that order). This way the scenario you mention does not<br>
> come up. We were not sure whether people would expect the DUNE_LIBS to be<br>
> part of ALL_PKG_LIBS. If so, the find scripts should prepend the flags<br>
> instead of appending them.<br>
<br>
</span>I used a dune lib because there the problem would definitely<br>
occur. Maybe that was a bad example. But there are other tests that<br>
depend on each other, e.g. ParMETIS -> METIS. Therefore we should try<br>
to make this right from the beginning. Even if it is just for users<br>
that might use our code as a template.<br>
<span class=""><br>
> PS: When you proposed to get rid of all the package-specific flags and<br>
> macros, did you think of a mechanism like this one or something entirely<br>
> new?<br>
<br>
</span>Actually, my idea was more radical. But I already kind of<br>
anticipated a misunderstanding when I saw it on the 2.4 list.<br>
<br>
My idea was to not to offer any dune_add_<bla> functionality, but always<br>
globally set the maximum available available flags globally (using<br>
include_directories and link_libraries) such that<br>
all binaries/libs are compile the same. Then we could stop forcing<br>
people to use our build system, by publishing all the flags/libs via<br>
pkg-config and cmake package configuration. Unfortunately,<br>
link_libraries seems to be deprecated for whatever reason.<br>
<br>
Of course I am totally unaware of the compile time increase that this<br>
produces and therefore this should be done in branch. With the current<br>
approach this can also be easily testable and might be a nice<br>
intermediate step.<br>
<div class="HOEnZb"><div class="h5"><br>
Markus<br>
<br>
--<br>
Do you need more support with DUNE or HPC in general?<br>
<br>
Dr. Markus Blatt - HPC-Simulation-Software & Services <a href="http://www.dr-blatt.de" target="_blank">http://www.dr-blatt.de</a><br>
Hans-Bunte-Str. 8-10, 69123 Heidelberg, Germany<br>
Tel.: <a href="tel:%2B49%20%280%29%20160%2097590858" value="+4916097590858">+49 (0) 160 97590858</a><br>
</div></div><br>_______________________________________________<br>
Dune-devel mailing list<br>
<a href="mailto:Dune-devel@dune-project.org">Dune-devel@dune-project.org</a><br>
<a href="http://lists.dune-project.org/mailman/listinfo/dune-devel" target="_blank">http://lists.dune-project.org/mailman/listinfo/dune-devel</a><br>
<br></blockquote></div></div>