modelica-3rdparty
Restructuring of the repository
Hi!
As my name suggests I'm working for ABB with this library. In order to understand how to work with the library, I quite heavily restructured the repository and decomposed externalmedialib it into different sub-libraries that are all linked into externalmedialib.
My question is the following: Would you possibly be interested in a PR containing the restructuring? I'll describe it in the following and would like some idea on how willing you would be to merge it/advice me on possible revisions such that you would then like to merge it, before I start the process of getting formal approval from my company for contributing the restructuring back to the project.
The pull request would in total contain the following:
- Project/Sources is decomposed into sub-libraries that are statically linked into libExternalMediaLib.so (or .dll etc.). These sublibraries have their dependencies described in their own CMake files.
- CoolProp is built and linked as a static library, so that this project can simply use coolprop's public include directories published by the CoolProp Cmake target instead of tracking coolprop's include directories manually.
- CoolProp is made (again, if I understand correctly) a git submodule. This also reduces the minimum cmake version to 3.9 (see #89 and the next point, right now it is apparently 3.18)
- To reclaim the performance that is lost by introducing static libraries instead of compiling everything together, cmake is instructed to check for IPO capabilities of the compiler (a.k.a. link-time-optimization) an activate them in case they are found. This raises the minimum CMake version to 3.9 (Without IPO it would be 3.8, because of the generator expression
target_compile_definitions(${LIBRARY_NAME} PRIVATE EXTERNALMEDIA_FLUIDPROP=$<IF:$<BOOL:${FLUIDPROP}>,1,0>)
)
5. Symbols are hidden by default and only those also exported under Windows are visible.
6. The outer usage would stay the same, apart from needing to clone the repository with --recursive because of the git submodule. Note that I don't have access to FluidProp, so can not test it.
Advantages are in my opinion the following:
- Clear dependency structure of the different parts of the library make it easier to reason about it and probably easier to maintain it in the long run.
- Easier to add unit tests (because of the smaller sub-libraries).
- Easier to track coolprop, because no knowledge of its internals is needed.
Disadvantages:
- Very old compilers may not support IPO and therefore there may be some performance drop. I haven't measured anything but would be surprised if this was a big drop.
I think this is a super nice opportunity. Please go ahead and prepare a PR - I will support the integration and I may also help with the CI part.
Just a quick heads-up: Any news on this will not come before mid-September.
Another heads-up: The application for open-sourcing the restructure is now in the process of approval. Unfortunately I cannot give a further time estimate but will of course report back as soon as I know more.