On Mon, Nov 23, 2009 at 11:27 PM, Alex Fabijanic <aleskx@...> wrote:
> On Mon, Nov 23, 2009 at 3:02 PM, Pau Garcia i Quiles <pgquiles@...>
>> On Mon, Nov 23, 2009 at 7:31 PM, Marian Krivos <nezmar@...> wrote:
>> > Anyway, basic Makefile fallback must stay here for the future for
>> > platforms without cmake support.
>> Do those platforms really exist? CMake essentially builds on every
>> platform I have tried, and for platforms where you need to
>> cross-compile, CMake >= 2.6.2 makes cross-compilation very easy.
> OK, here's my proposal/appeal:
> Can someone (Marian, wink, wink) "officially" take the responsibility for
> Visual Studio solutions/projects in the trunk? This means keeping CMake
> files up to date so we can count that, when we release the trunk code, we
> can generate the solutions for the release from CMake files. I've been
> keeping it up to date manually, but with VS 2010 that will not be possible
> As for non-windows builds decision, I'll leave it to Guenter (and whoever
> else wants to speak on it) to decide whether he wants to keep the POCO
> makefiles in addition to, or drop them in favor of CMake generated ones. I
> have personally been quite happy with POCO build system there (it shows well
> Guenter's gift for turning a dreadfully incomprehensible system into one
> that is almost fun to use ;-). But, I also clearly see the benefit of having
> a single build system if it will truly cover all the platforms.
> One thing I am against is introducing a dependency on any build tool other
> than gmake for released code. So, even if we say we'll have CMake generate
> non-windows makefiles, those should be generated for releases, so the users
> can just download POCO, compile and go.
IIUC, you want to generate Visual Studio solutions and Makefiles for
Unix-like platforms from CMake projects, right?
Unfortunately, that is not possible. CMake-created .vcproj's, .sln's,
Makefile's, etc contain absolute paths, which make them impossible to
move around. See:
That being said, there is an variable in CMake to try to create
vcproj's, Makefile's, etc with relative paths but it's not thoroughly
tested and well, don't ever complain if it fails :-)
Use relative paths (May not work!).
If this is set to TRUE, then the CMake will use relative paths between
the source and binary tree. This option does not work for more
complicated projects, and relative paths are used when possible. In
general, it is not possible to move CMake generated makefiles to a
different location regardless of the value of this variable.
Although it requires the CMake executable to be present for building,
you should consider moving to CMake and abandoning manually-generated
Makefiles, Visual Studio projects, etc.
CMake is a very good tool and very easy to use.
It took me a long time to convince people at work to move to CMake
from custom Makefiles for Unix + .vcproj/.sln for Windows but it's the
best decision we have ever taken and people are very happy we moved to
CMake. Supporting new platforms is now trivial. CMake automagically
finds 3rd party dependencies via FIND_PACKAGE. No need to manually
synchronize Unix makefiles and Visual Studio projects. Plus we now
have CTest, a CDash dashboard where we can submit the results of our
daily builds. And you can easily generate NSIS installers for Windows
and .dmg for Mac with ready-to-use binaries of Poco.
Pau Garcia i Quiles
(Due to my workload, I may need 10 days to answer)