[Dune] Improve module handling by CMake

[Oliver Sander]

Hi Simon,

> - There is some name irritation in the last mails. You speak about config-files. Do you mean the generated `config.h` file, or do you mean the `PackageConfig.cmake` files? 

the latter.  Sorry, I am not sure what their official name is.


> - Should we create some kind of working group to go into the details of the cmake system? How could this be organized?

How about we open a meta-bug for dune-common and chart out a roadmap there.
Then assign individual steps to volunteers (provides these exist) and discuss
technical issues of the individual steps in separate gitlab issues.

Cheers,
Oliver


 I think, sending messages here to the mailinglist is a good starting point, but makes productive discussion complicated. Maybe some topic specific Matrix/Slack/Mattermost/... chat room? Or a GitLab Issue in the dune-common repo?
> 
> Best,
> Simon
> 
> Dr. Simon Praetorius
> Institut für Wissenschaftliches Rechnen
> Fakultät Mathematik
> Technische Universität Dresden
> Tel.: TUD-34432
> Mail: simon.praetorius at tu-dresden.de
> Web: www.math.tu-dresden.de/~spraetor
> 
> ________________________________________
> Von: Dune <dune-bounces at lists.dune-project.org> im Auftrag von Oliver Sander <oliver.sander at tu-dresden.de>
> Gesendet: Donnerstag, 30. April 2020 06:51
> An: dune at lists.dune-project.org
> Betreff: Re: [Dune] Improve module handling by CMake
> 
> Hi Christoph,
> 
> thanks for the detailed explanation.  Is this sequence of steps
> something that people agree upon?
> 
>> 1. Use CMakeCache.txt from dependencies to avoid re-running checks in
>> later modules.
> 
> As a cmake non-expert I am surprised by this.  Are the CMakeCache.txt files
> really intended to be used like this from third-party software?
> 
> You yourself pointed me to those config-file packages, and I wonder why
> we cannot use those?  AFAIU these would solve a separate problem:  I have
> gotten reports from people that want to use Dune modules like just another
> library.  This fails, because Dune modules don't export the relevant information.
> 
>> We need to add some extra sorting, as there is not always
>> a unique ordering. Take dune-common, dune-geometry and dune-istl. When
>> dune-geometry is run prior to -istl, dune-istl must use -geometry's
>> cache and not -common's.
> 
> Hmm, wouldn't I just merge the two CMakeCache.txt files and discard
> duplicate information?
> 
> Best,
> Oliver
> 
>  Dune-grid has to pick up -istl and so on.
>> Easiest solution would be alphabetical sorting of names to get a unique
>> ordering.
>> After this step, dune modules would know the CMake variables in later
>> modules.
>>
>> 2. Create individual config.h files, for dune-foo this could be
>> dune-foo-config.h. For every dependency dune-bar dune-foo-config.h would
>> include dune-bar-config.h.  We can stick to config.h, which includes
>> dune-foo-config.h.
>> After this step, dune modules know the C preprocessor macros.
>>
>> 3. Improve handling of linking libraries. CMake offers private and
>> public interface propagation.
>> After this step, linking and passing additional arguments would be more
>> CMake-ish.
>>
>> 4. Fix everything that I currently forgot. Get rid of many Dune-ism,
>> that one wouldn't write today, that I am even not aware of.
>>
>> If others have different ideas, please share them!
>>
>> Bye
>> Christoph
>>
>> _______________________________________________
>> Dune mailing list
>> Dune at lists.dune-project.org
>> https://lists.dune-project.org/mailman/listinfo/dune
>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5198 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20200430/de4b36ac/attachment.bin>