Portable C++ build system [closed]_问答_开发者

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.

Closed 7 years ago.

Improve this question

I'm looking for a good and easy in maintenance portable build system for C++ projects. Main platforms should include Windows (Visual Studio 8+) and Linux (gcc); Cygwin may be an advantage. We're considering two main possibilities: CMake and Boost.Jam. SCons can be also an option, but I haven't investigated it yet. CMake and Boost.Jam seem to have the following traits:

CMake:

(+) generates native "makefile" (solution for Windows, project for Eclipse)
(+) extensions for testing and packaging
(-) demands a configuration file in every project folder
(-) based on a little too verbose peculiar language

Boost.Jam:

builds by itself with no intermediate steps
(-) doesn't generate native solutions/projects
(+) concise language similar to the classic makefile
(+) intuitive support for properties like multithreading and static/dynamic library

Wha开发者_如何学JAVAt are other possibilities and what is really preferable after experience? What build systems can create a solution on the way?

(-) demands a configuration file in every project folder

This is not correct, you just need to pass bigger pathes like:

add_program(foo src/foo.cpp src/main.cpp)

Few notes, about Boost.Jam - first it is not Boost.Jam - bjam on its own quite useless, what you are looking for is Boost.Build which is set of Jam macros that make bjam useful.

Now, I worked with both, and I must admit, Boost.Build is not suitable for any serious projects outside the Boost itself. Need to find library? Can't need to find header? Can't. Need to do something outside of simple build - and you have not idea how to do it as BB documentation... Totally useless and maybe cover 10% of BB. So most of cases you need to ask questions in BB mailing lists and...

So, if you have some complicated project - and you need to make something more then simple compile and link, stay away from Boost.Build.

So if you need to support MSVC I find today CMake as only feasible choice.

I don't tell that CMake is very good system, it has many problems but it is something mostly suitable for cross platform development (if you need to support MSVC).

And if you don't care about MSVC and happy with MinGW... take a look on autotools as well.

About Scons - it is still less mature them CMake.

This is a bit of a rant, but I'll try to stay objective and only report my experiences:

I have tried CMake on several occasions and I'm close to reaching a point where I will volunteer to either maintain separate project files for each build environment or abuse another language's build system (Ant, NAnt, MSBuild or so) to compile and package my C++ projects.

CMake, as it is:

It replaces an ugly, but formalized format (Makefile) with an incredibly poorly designed free format (CMakeLists.txt)
It dumps its configuration, cache and other clutter all across the directories with zero respect for the user's attempts to keep the source tree clean.
The documentation for CMake is be lacking in most places (for example, try to recursively add a source directory to a target wile excluding certain files for starters)
The generated IDE projects are incredibly poor (have a well-structured Visual Studio project? CMake will dump all your sources into a single project node)
The generated IDE projects use absolute paths (so you can't check them into source control -- everyone has to use CMake)
You can only pick between platforms (eg. x64 and x86) when generating projects / makefiles. CMake won't generate projects supporting multiple platforms even if the IDE would be perfectly fine with this.
Very little control over how libraries are referenced. There is an array of reference finding methods (so even with the poor control, you can expect no uniformity whatsoever).

My personal view is that even if one wanted to intentionally design the worst cross-platform build system possible, it would be hard to do any worse than CMake.

I don't have any experience with Boost.Build and it may well have equally drastic shortcomings, but the best I can say about CMake is that if your only care is to get some source files built somehow, it can get the job done -- albeit with much pain for the developers and the library/application consumers.

I've had some good experiences with premake4: http://industriousone.com/premake

Update

I do still like premake, but after working with it awhile, I feel obligated to list some of the shortcomings I've found in it:

Integrating new toolchains (i.e. preprocessing tools like bison or moc) isn't supported.
No support for per-file configuration.
Library finding is inflexible, no support for scripting or version checking.
Some directives (e.g. configuration) affect following statements, but there's no explicit scope delimitation. This can lead to subtle errors.
Little support for debugging the configuration, in other words, showing how the configuration is being interpreted, other than examining the generated build scripts or running them.
For gmake Makefiles at least, there's no option to make paths absolute. This doesn't play well with Vim's quickfix, although it's easy to work around.
Slow development pace. New features can be in development for years.

I'll follow @Akusete on QMake, which is my personal tool of choice for now. Pros and cons are a bit personal too, but here they are:

Pros:

Much conciser script language, compared to CMake;
Can generate both VS projects and jom-compatible makefiles on Windows;
Adding toolchains for, say, cross-compilation is quite easy (boils down to a customised mkspec, which is written in the same qmake language);

Cons:

A bit limited freedom of making arbitrary number of targets. There are some predefined ones, like app, lib etc., but it's a bit cumbersome to build, say, both shared and static library versions in a single pass, or disable precompiled header for a single source file. It's definitely achievable, but requires some googling and looks dirty;
Tied to Qt by default (which is easily overridden by addition of QT -= core gui line)

Overall:

Gets the job done quick on simple-to-medium projects, but still leaves the feeling of "damn, it could have been done in a simpler way!" when applied to complex tasks.