Build both .so and .a files

[emiliofernandes]

Hello ADIOS2 community and Happy new year!

I need to provide ADIOS2 both as dynamic and static libraries to the users. I.e. the users will decide whether to use it as a dynamic or static library depending on their needs.

I know that I can control that with the BUILD_SHARED_LIBS flag.

My question is:
Is it possible to build both .a and .so in one build step ?
If it is not possible then would there be a problem if I run cmake .... twice - once with -DBUILD_SHARED_LIBS=ON and a second time with -DBUILD_SHARED_LIBS=OFF and make install them in the same location ?

I can install them at two different locations but it would be cool if both types of users use the same location to find the dependency.

Gracias!

[eisenhauer]

Hi Emilio! IMHO This is really as much a CMake question as it is an ADIOS question, though certainly the ADIOS CMake configuration is involved here. As such, I'll punt it to our Kitware team @caitlinross and @vicentebolea.

[caitlinross]

I don't think there's a way to build both shared and static in one step, without us making changes to the CMake files, but I don't think it should be a problem to do the two builds like you say and have them installed to the same location.

[eisenhauer]

So, I'm curious about this. Not in that you could get both the dynamic and static libraries to exist in the same install directory; that's obviously trivial. But we also install cmake targets files, etc. that might contain embedded paths, filenames, etc. Would installing one first and then the other cause the 2nd install to overwrite these files from the first install? What would effect would that have on clients trying to use CMake to find ADIOS libraries?

[caitlinross]

Yeah I wasn't sure about it, so I tested it out with building ADIOS both ways and installing to the same location, then building Fides and seeing what gets used. It was working for me, but I realize now I misread the verbose output I got from ninja earlier, so yeah it looks like whatever you built most recently will be what gets used.

So the solution is to install to separate locations. To install to the same location, it does look like we'd have to make changes to the CMake files.

[williamfgc]

@emiliofernandes hola, the way to tackle these conflicting scenarios is by building separate variants as mentioned by others. See conda packaging separating openmpi and mpich (not the same, but similar solution to two incompatible dependencies). I'd keep consumption when linking with apps completely separated as well to avoid errors. Hope it helps.

[emiliofernandes]

Thank you all for the comments!
Really appreciated!

[emiliofernandes]

I don't see how to mark this discussion as closed. None of your replies has a button "Mark as answer" or similar...

[eisenhauer]

I've converted to a Q&A, rather than general discussion so you can mark an answer.

[vicentebolea]

An alternative suggestion is to create a Cmake project that is a composite of two ADIOS2 builds using the ExternalProject_Add and later merge the files located in the two prefix/lib directories into a final directory that will be presented to the users. This will allow you to automatize the two builds of ADIOS2.