On 30/03/2017 02:10, Robert Dailey wrote:
Interested in hearing everyone's thoughts on this idea of mine.
Right now I have several third party libraries: openssl, boost,
libpng, zlib, etc. List goes on. I need to support these libraries on
at least 3 different platforms: ARM android, x86 linux, x86 windows.
It's a real pain in the rear to build each of these libraries a total
of 3 times (once per platform). It makes upgrades painful.
So I was thinking: If I set up each third party library to build from
source as a normal target with the rest of my targets, this would get
me the libraries for each third party lib "for free". Basically, they
would all build the same way no matter what platform I'm on. I can
move to other platforms or architectures in the future with no extra
effort.
This is known as "super build".
Yes, this is exactly why I made my Boost CMake build scripts, which you
use unless you changed your mind today :)
It can be done for other projects as well. Sometimes, they even provide
CMake build scripts you can use directly with "add_subdirectory()" so
you don't have to write CMake scripts or use "ExternalProject_Add()"
(which isn't all great since it doesn't propagate all your current
project settings).
The downside, of course, is that they build along with my normal
targets. Which means doing "ninja clean" will clean them, when I
really don't need to, and it will make build times get longer.
You can use ccache or its Windows variants to make it faster. But you
also shouldn't need "ninja clean" most of the time. Possibly, you could
just clean a specific target "ninja -t clean foo".
If you declare all your dependencies properly, then you could just
always run "ninja" and the build will just be correct.
If your purpose is to see the compiler output again (to fix warnings),
it is acceptable to clean and rebuild (with ccache it should be fast
enough).
Personally, I just have a very long history in my terminal and scroll
back or pipe the build content to a file to look at it later. Some IDEs
will also record all the compilation output and make it available later
(Xcode does it), then it's less of an issue.
Any thoughts on this idea? Are there any other downsides? Is this the
best way to have library support across platforms?
The downside is that you have to maintain lots of 3rd party build
scripts. Depending on the side of the project, it might be a big
overhead for the team. But it might also be totally worth it in order to
support a lot of platforms, it just makes it easier than handling a huge
matrix of binaries for each platform, arch and compiler and compiler
options.
"Hey, you want to try LTO? Just add the flag and it's done!".
/Florent
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
