Home  /  RSS  /  RSS Comments  /  Enter

Why CMake sucks... (once more)

1/26/10, by artyom ; Posted in: Progress; 17 comments

Edit: I would give a credit to CMake team for fast response and the update of CMake wiki about fixing this issue.

So maybe "CMake sucks less" ;-)

For last week I tried to figure out what is wrong with MSVC build. It used to work once recently it had failed with wired linker error.

After long tests I had found, sometimes I get linker errors on missing import symbols and sometimes not... I thought some build flags were wrong or something like that, till I tried to link manually from command line with my dll and started searching for import library. So I found cppcms.lib, but linking fails again -- with hundreds undefined symbols.

So I had tried static version... And I could not find it. At this point I become suspicious: can static library and import library collide with each other?

After some Googling I had found -- they indeed collide! WTF?#$%#$%!$ After that I tested behavior on various platforms:

Linux/gcc:

shared: libfoo.so
import: ---
static: libfoo.a

Cygwin/gcc:

shared: cygfoo.dll
import: libfoo.dll.a
static: libfoo.a

Windows/MinGW:

shared: libfoo.dll
import: libfoo.dll.a
static: libfoo.a

Windows/MSVC:

shared: foo.dll
import: foo.lib
static: foo.lib <---- Collides!!!

I order to solve it, I had to write something like that for special MSVC compiler.

if(MSVC)
   set_target_properties(cppcms PROPERY IMPORT_SUFFIX "_imp.lib")
endif()

So the question is:

Why do I need build system?

To write my own rules for each possible platform? No! CMake did the correct naming rules for Cygwin and MinGW import libraries but they didn't for MSVC?

The hole purpose of moving to CMake was support of MSVC compiler, because autotools support Cygwin and Win32/MinGW builds perfectly. And even this simple stuff was not done right!

I must admit, it was simpler to write cross platform code then to perform cross platform builds!

P.S.: Maybe I should stick with Autotools and write independent MSVC solutions for brain damaged MSVC compiler?

P.P.S.: Opened Bug Report

Notes

I received a feedback from the bug report with suggestion:

There is no need for an "if(MSVC)"... This should work:

   set_target_properties(foo-static PROPERTIES
                         CLEAN_DIRECT_OUTPUT 1 
                         OUTPUT_NAME "foo"
                         PREFIX "lib")

It will cause this:

  shared: foo.dll
  import: foo.lib
  static: libfoo.lib

Comments

fake_ik, at 1/26/10, 5:21 PM

Obligatory:

bla bla bla ... FreePascal is better ... bla bla bla

artyom, at 1/26/10, 5:33 PM

;-)

fkrauthan, at 2/27/10, 11:37 PM

Hi, why dosen't you use premake?

artyom, at 2/28/10, 11:45 AM

Hi, why dosen’t you use premake?

1st, I haven't heard about it before. Also how mature is it in comparison to autotools, CMake?

fkrauthan, at 3/3/10, 5:59 PM

Its a very simple autotool. Its definition files are lua scripts. Here you can find the homepage: http://industriousone.com/premake

Mateusz Loskot, at 3/22/10, 2:13 PM

Artyom,

I agree and I don't agree at the same time. It looks there is no build system that would fulfil your requirements and make you happy using it. Yes, there is no such build system ideal for all platforms and coping with all caveats on all platforms.

What would be your comment about Boost.Build?

artyom, at 3/22/10, 4:43 PM

It looks there is no build system that would fulfil your requirements and make you happy using it.

There is one that I was quite happy with it -- autotools. But unfortunately it does not supports MSVC. To be honest. Dropping support of this compiler would solve me lots of headache even for CMake.

But you know... autotools has its own glitches, but at least it has long history and works well for most platforms including Cygwin/Mingw (where BTW, so-name convention with CMake is broken) And it has all useful features project needs: test, deploy, build, configure and so on.

I still admit that some CMake features I like, it is easier to work with out of source builds with CMake and Debug/Release/DebWithRelInfo setups are nice.

And also I hate its syntax. Why set(foo "bar") instead of foo="bar"?

What would be your comment about Boost.Build?

Ohhh... This is total crap.

If documentation of CMake is quite bad the documentation of Boost.Build just does not exits. If I would not try to push Boost.Locale to Boost I would not even try it. I hope this nightmare with Boost.Build will end.

BTW, till few versions ago, boost-build had totally broken support of Cygwin shared libraries.

I hope that one of these would happen:

  1. Windows would die so I do not have to support crappy dlls
  2. MSVC would die so I do not support crappy way of creation of dlls.
  3. MSVC would support ANSI C flags like -lfoo -L/path etc. So autotools would work with it.
  4. Autotools would support MSVC natively
Mateusz Loskot, at 3/22/10, 10:13 PM

But unfortunately it does not supports MSVC.

Lack of this is not "just" or "only", because it would be difficult to add as autotools are tightly coupled with Linux/Unix-like environment and file system. If we consider use of Visual C++ as a requirement of a build system, Autotools are out of discussion here, as they are useless.

I don't even consider Cygwin or MinGW as these are a complete prosthesis under Windows and not native development environment.

Given that, CMake does good job trying to provide decent usability in terms of real portability of configuration. CMake documentation is IMHO much more accessible than Autotools. At least, CMake fundamentals are presented in one place, presented gradually from basics to advanced elements. Autotools docs are way more scattered.

Boost.Build docs are not best, but there is a will to improve them. Volodya is doing really good job, he is open for suggestions. So, I'm sure he would appreciate to hear comments from you, though not comments saying "it all sucks" but constructive comments.

Given the list of your hopes, I suppose I'm more realistic. I presume neither of 1 or 2 is going to happen soon, and that's why CMake and Boost.Build are happening.

I'm curious, what part of the C Standard specifies -l or -L flags.

artyom, at 3/22/10, 10:52 PM

I don’t even consider Cygwin or MinGW as these are a complete prosthesis under Windows and not native development environment.

It is the question of point of view. If you consider native development as working is VS and IDE then maybe, otherwise...

MinGW, is today the only feasible option to get good free C99 compiler for Windows, without it you would not seen many good software under Windows like Gimp, FileZilla and many others.

Boost.Build docs are not best, but there is a will to improve them. Volodya is doing really good job, he is open for suggestions. So, I'm sure he would appreciate to hear comments from you, though not comments saying "it all sucks" but constructive comments.

There is one biggest issue with Boost.Build -- it is suitable for Boost only. If the build system does not provide built-in option like find_library, check_cxx_compiles etc... The system that half a year ago wasn't capable to build shared libraries correctly under Cygwin, It is not considered general purpose build system.

However I do try to be constructive... At least I pointed to the issue with Boost.Regex ICU incorrect linking of debug regex build with release ICU under MSVC.

I'm curious, what part of the C Standard specifies -l or -L flags.

My bad, it is not C standard but rather POSIX standard, See:

http://www.opengroup.org/onlinepubs/9699919799/utilities/c99.html

BTW, cl does supports some of options, but they are not documented anywhere...

artyom, at 3/22/10, 11:01 PM

One more note... About being constructive.

I use CMake, report bugs and try to make it more useful (suck less).

But still I think it is far from being fully mature software. In future maybe, but not now... I wish CMake and BB get improved.

Mateusz Loskot, at 3/23/10, 12:34 AM

Visual C++ is a good compiler/implementations of for current and upcoming C++ standard. I'm not discussing C99 as C99 is not part of current C++ standard. I'm focused on Boost, so C++ compiler and Visual C++ is a good one.

AFAIK, Boost.Build is being updated with features like 3rd-party libraries lookup. I agree, Boost.Build feels Boost specific and that's one of the reasons why it doesn't provide such functionality yet. Talk to

Regarding ICU and linking, yes I've seen it. Mixed debug/release runtimes is a well-known issue on Windows. Also, there is no unified naming or location for binaries in various configurations. However, these problems are resolvable.

What specific cl.exe options are you referring to? Any or some options means anything or everything. Compiler options are well-documented, I would say. Here is alphabetic list: http://msdn.microsoft.com/en-us/library/fwkeyyhe.aspx

CMake and Boost.Build are mature software packages. However, there is plenty to get done to make them covering all aspects of multiplatform and portable builds, certainly.

FYI, FileZilla and GIMP can be compiled using Visual C++.

artyom, at 3/23/10, 7:04 AM

Visual C++ is a good compiler/implementations of for current and upcoming C++ standard. I'm not discussing C99 as C99 is not part of current C++ standard. I'm focused on Boost, so C++ compiler and Visual C++ is a good one.

That is exactly what I mean. From narrow point of view of Boost developer, MSVC is fine (and it is indeed good C++ compiler). But from the wider point of view MSVC totally lacks support of C99 (MSVC is C compiler as well...).

What specific cl.exe options are you referring to? Any or some options means anything or everything. Compiler options are well-documented, I would say. Here is alphabetic list: http://msdn.microsoft.com/en-us/library/fwkeyyhe.aspx

I mean, cl receives some POSIX command line options. I mean you can even compiler

cl -I/path/to/inc foo -o bar.exe

And it would work. But these flags are not mentioned in the MSVC documentation you had pointed to.

FYI, FileZilla and GIMP can be compiled using Visual C++.

Are they? At least I didn't find any MSVC mentions in filezilla build instructions and neither in GIMP once's.

LM, at 6/26/14, 10:09 PM

I'm also not thrilled with cmake and the state of most cross-platform build systems. Many have too many dependencies when you just want to build a simple C/C++ applications. I've had trouble with various versions of cmake just getting them to build from source. If cmake builds, it has trouble finding my include and library locations. I'm using pkg-config (actually pkgconf) for all my libraries. You'd think it would be easy for any tool to query pkg-config and get the right information. I personally prefer a makefile with the right conditional statements and calls to pkg-config to find libraries and dependencies over many of the other methods. Using a preprocessor, I can generate makefiles with specific platform defaults. If one really needs something on the style of autotools to check if a feature is available, cDetect looks like it can do the job and it doesn't need Perl, m4 and several other dependencies.

The reason I wanted to post was to mention that one theoretically could use make/autotools with MSVC. OpenWatcom had a similar issue with incompatible flags so they designed a front-end to their compiler and linker (owcc). There's a similar tool for the MSVC command line compiler available with Microsoft SFU/SUA.

Chris, at 10/31/14, 5:30 PM

Not understanding MSVC build conventions and then blaming it on CMake is hardcore. Not having any other option than CMake and so being bitter is hardcore. Making a blog post saying CMake sucks in the middle of an open bug report to the CMake team is hardcore. Way to be so harcore! I'm sure the CMake devs were so happy to take the time to help you while you took a shit on them :D

X, at 12/14/17, 1:52 PM

I wish the CMake developers would stop developing cmake. Then maybe it would die, and they would stop wasting their time.

But maybe they would ruin another field if they weren't busy wasting everyone's time developing a tool that in fact is worse than nothing.

Network effects are hell.

artyom, at 1/16/18, 1:37 PM

@X I must say since 2010 CMake improved a lot and today it is my general choice for build system.

aron, at 4/19/18, 8:44 AM

Try scconfig! http://repo.hu/projects/scconfig/

open source configuration utility, and depends only on C89 compiler and a very dumb make tool

Add Comment:

 
 the email would not displayed
 

You can write your messages using Markdown syntax.

You must enable JavaScript in order to post comments.

Pages

Categories