Making fixed paths in dependency target optional

[tdegeus]

No description provided.

[ferdonline]

Thanks for the suggestion @tdegeus.
I added a few comments on things that I think can be improved.
One thing, please don't reformat the whole file, it makes it hard to track, and we have in this project the convention of 2 spaces and using

command(PROPERTY val PROPX val2)  # Fits small line

command(PROPERTY val1
        PROPERTY val2)
or 
command(MODE
   PROPERTY
       val1
       val2
)

[ferdonline]

why not providing target project with options? Users would appreciate I believe

[tdegeus]

It is unclear to me how one can ever reach these options. Can you given and example CMakeLists.txt where you reach them?

[tdegeus]

In terms of the command-line options, yes is should be there, but only HighFive's CMakeLists.txt. Which I think it is, but we should double check.

[tdegeus]

I will revert the indentation. Though since the entire project is four space, I think it should be four spaces also here.

[tdegeus]

@ferdonline Can you check/comment if things are to your likings now.

[tdegeus]

I just realised that the static target is inherently restricted to old CMake behaviour. In particular, the static target will only work for those libraries that do not provide modern CMake targets. Those that do, will always require to call find_package(ModernLibrary) before using the target. I.e. the new way of doing things in CMake is exactly to get rid of static dependencies including the possibility to dirty hack them in, as we just did. I guess that the only way to keep dirty hacking it in is to hard-copy all the targets' components, but this seems at odds with the direction that CMake is purposefully moving to.

The static dependencies should therefore be removed from HighFive altogether. Thereto I see the following options:

• The static dependencies are removed all-together from this commit forward.
• That HIGHFIVE_USE_INSTALL_DEPS option is only introduced to ease the transition, but directly accompanied by a deprecation warning. If this option is chosen, we should remove the modern Boost targets.

[tdegeus]

I have pushed a proposal for how I think the user can still provided with everything there was before, but the user is not automatically invited to keep using old features and warned that these features will disappear in the future.

Curious to hear your feedback.

[ferdonline]

Tom I appreciate your contribution here but, although you solution seeks to be more elegant, it ends up being more complex and introducing limitations. The limitations being that it doesnt seem to perfectly work with the older systems, and second when we default to not use the detected libs they wont be exported and so, even if the end application wants to change the default and actually use them, it's not possible anymore.
With that in mind I think we should favour the initial solution.
Please let me know of eventual limitations or cases we must still work out.

[tdegeus]

@ferdonline With this things should be how you like them.

[tdegeus]

Any news @ferdonline ?