Home  /  RSS  /  RSS Comments  /  Enter

New version of Boost.Locale released

Saturday, March 13, 2010, by artyom ; Posted in: Progress, Unicode and Localization; 0 comments

New version of Boost.Locale releasedI'm glad to introduce updated version of Boost.Locale library: This library was designed for Boost and created because of needs CppCMS framework.

Boost.Locale is a library that brings high quality localization facilities in C++ way. It provides the natural glue between C++ locales framework, iostreams and powerful ICU library giving:

New in this version:

  1. Fully redesigned break iterator interface
  2. Added date_time and calendar support that allow manipulating with dates over non-Gregorian calendars
  3. Implemented full set of unit-tests
  4. Added support of many platforms and compilers.
  5. Lots of bug fixes.
  6. Complete reference with Doxygen
  7. Many tutorial updates, thanks to Markus Raab inputs

So if you are interested:

Why CMake sucks... (once more)

Tuesday, January 26, 2010, 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

CppCMS 0.0.5 (Stable) Released

Monday, January 11, 2010, by artyom ; Posted in: Progress, Framework; 6 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

Saturday, November 14, 2009, 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

Thursday, November 12, 2009, 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.

previous page

next page

Pages

Categories