Home  /  RSS  /  RSS Comments  /  Project Site  /  Enter

Why CMake sucks... (once more)

26/01/10, by artyom ; Posted in: Progress; 2 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

CppCMS 0.0.5 (Stable) Released

11/01/10, by artyom ; Posted in: Progress, Framework; 0 comments

Hello All,

Version 0.0.5 of CppCMS framework (stable brunch) had been released. So far:

Security Bugs:

Bugs:

Improvements:

MSVC9 is now supported by CppCMS

14/11/09, by artyom ; Posted in: Progress; 0 comments

MSVC 2008 had successfully compiled CppCMS 1.x.x branch and run several examples. So it looks like that Windows with MSVC would definitely be one of the officially supported platforms. (Note: 0.0.x stable branch would not support Windows besides Cygwin)

The biggest problems I had with MSVC were lack of support of C99 and some POSIX functionality like: snprintf, cstdint or gmtime_r… but with couple of ifdefs it mostly solved.

To be honest, Windows development can be quite unpleasant, especially with lack of basic widely available libraries like zlib. But finally I must admit that it is possible to work with Mircosoft compiler, I could even admit, it could be very fine compiler if it was supporting C99.

Also, more time I try supporting Windows platform, more I understand: gcc is not as polished under Windows as it is under Unix platforms. That makes development of cross platform software even harder.

CppCMS 1.x.x moves to CMake

12/11/09, by artyom ; Posted in: Progress, Framework; 0 comments

No, I don’t think that CMake is better then autotools. In fact I still think that CMake is total "crap". It has terrible cache policy, it has broken configuration_file support. It is crappy documentation and many broken configuration tools like CheckTypeSizeOf… and much more.

But it supports MSVC (that I may think supporting in future) and has a better Windows support… So I announce that next version of CppCMS would use CMake (and it already uses in re-factoring branch).

Autotools build system is no longer supported and will be removed from the CppCMS 1.x.x branch, because I do not really like supporting two build systems.

I hope CppCMS users would understand this terrible move.

Introducing Boost.Locale

08/11/09, by artyom ; Posted in: Progress, Unicode and Localization; 0 comments

After a long period of hesitating I had understood – standard C++ locale facets are no-go and started developing localization tools based on ICU that work in C++ friendly way. Thus, Boost.Locale was born. It had just been announced to the Boost community for preliminary review.

Boost.Locale provides case conversion and folding, Unicode normalization, collation, numeric, currency, and date-time formatting, messages formatting, boundary analysis and code-page conversions in C++ aware way.

For example in order to display a currency value it is enough to write this:

cout << as::currency  << 123.34 << endl;

And currency like "$124.34" would be formatted. Spelling a number?

cout << as::spellout << 1024 << endl;

Very simple. And much more. This library would be the base for CppCMS localization support and I hope it would be also accepted in Boost at some point in future.

I've tested this library with:

Documentation

Source Code

Is available from SVN repository.

svn co https://cppcms.svn.sourceforge.net/svnroot/cppcms/boost_locale/trunk

Building

You need CMake 2.4 and above, ICU 3.6 and above, 4.2 recommended So checkout the code, and run

cmake /path/to/boost_locale/libs/locale
make

Inputs and comments are welcome.

next page

Pages

Categories

Development

Powered By

3rd Party