Regarding Poco build system

[ghost]

I've been poking around with Poco source code lately, and found out that the build system is really broken.

I would like to know if CMake is going to be the 'official' way to build Poco, because there are some odds that need to be fixed (like the third-party dependencies mixed along with Poco source code).

Perhaps Poco should support only one way to build it's libraries since it is way easier to mantain than a bunch of VS projects and outdated makefiles.

[aleks-f]

Contributing to CMake is welcome and encouraged, we want someone to own it and take good care of it. However, not everyone uses CMake; we want to build "out of the box", supporting what is already present on most systems and that is gmake/VS. So, gmake and Visual Studio support will remain; contributions there are welcome as well. In fact, we've been looking for the build system maintainer for a long time but nobody stepped up and stuck around yet.

I would not agree that our makefiles are "outdated". You could be referring to the fact that, on different platforms, libraries (e.g. ODBC, MySQL) may be in different locations but there is a remedy for that through configure script.

At any rate, we want someone to own the build system; if you want to contribute toward either CMake or gmake/VS build systems, please do.

[ghost]

I would like to contribute to the build system, but I have a few questions before doing any work:

• Can Poco use a script generated UCD instead using PCRE just for Unicode support?
• Why are there the source code of V8's BigNum implementation floating around on Foundation folder?
• Is a good idea moving the third-parties to specific folder (zlib, expat, libharu)?
• What platforms Poco mainly support, so I can be sure it will compile out of the box without too much trouble?

[ghost]

Why are there the source code of V8's BigNum implementation floating around on Foundation folder?

Found out it's for NumericString implementation. Sorry.

[aleks-f]

I'll leave the UCD/PCRE answer to Günter.

Why are there the source code of V8's BigNum implementation floating around on Foundation folder?

No particular reason other than that's how it's been done with 3rd party embedded code from the start. No need for additional include directories would be the only benefit I can think of.

Is a good idea moving the third-parties to specific folder (zlib, expat, libharu)?

Possibly. I though about it myself before but never had time to dedicate to it.

What platforms Poco mainly support, so I can be sure it will compile out of the box without too much trouble?

See http://pocoproject.org/features.html
Most of our users are on one of the big three - Linux, Mac, Windows.

[aleks-f]

Note that I've embedded the V8 double-conversion differently from how embedding 3rd party libs was done before; I included *.cc files directly from the sources, so the build system does not have to worry about them. It would have to be elaborated on to support the "unbundled" feature.

[patrickjwhite]

I personally am a big fan of cmake. I totally understand the build out of the box thing though. I have seen a solution a few times where a released cmake source is part of the 3rdParty directory, and a bootstrap script would create the cmake binaries, and put the 3rdParty/cmake/bin/cmake into an environment variable which would then be used.

Just an option, but supporting a very basic script, and cmake would be much easier than to support so many different options.

[aleks-f]

Any contribution is welcome as long as it makes sense (and if large someone steps up to own it). I've been through many pains with our build system and I'd be the biggest proponent of a system that would (a) build out of the box (ie. no external deps) and (b) produce VS solutions/projects versions 2003-2012 with filters as we need them. There's been many discussions and proposals; they boiled down to CMake and Premake but (a) neither had all the capabilities at the time and (b) nobody really stepped up to own* the build system so far. Things may have changed; by all means, fork, do the work and send pull request.

• When I say "own", I mean someone actually being there we can count on to do the work for releases. Over years, we've seen people come, contribute code, and disappear. Contributions are certainly welcome, but the big ones are also additional maintenance baggage we end up carrying as we are moving on.

[ghost]

Today CMake can bootstrap, download and build external dependencies, generate IDE solutions and makefiles as well, and take care of the entire packaging process. It would not be that hard to wipe the actual build system and put on based on CMake.

I hope to contribute always when possible but I'm still waiting feedback on the UCD thing, mentioned here #29 (comment).

[aleks-f]

We're getting ready to release next week so it's a bit hectic time for accepting contribs ... regarding UCD, PCRE is used for Poco::RegularExpression so generating our own UCD would not help to remove that dependency. Once we move to C++11, we'll be able to do that.

[aleks-f]

It would not be that hard to wipe the actual build system and put on based on CMake.

Specific showstoppers I remember from some time ago:

1. Requirement to have CMake installed on target machine
2. no way to generate VS project filters for POCO
3. generated VS project files couldn't be moved (include/lib dirs were not relative, this was needed to alleviate 1)

At any rate, the best route at tis time is to keep the existing build system and work on CMake.

[RangelReale]

Em 15/12/2012 18:13, "Aleksandar Fabijanic" notifications@github.com
escreveu:

Any contribution is welcome as long as it makes sense (and if large
someone steps up to own it). I've been through many pains with our build
system and I'd be the biggest proponent of a system that would (a) build
out of the box (ie. no external deps) and (b) produce VS solutions/projects
versions 2003-2012 with filters as we need them. There's been many
discussions and proposals; they boiled down to CMake and Premake but (a)
neither had all the capabilities at the time and (b) nobody really stepped
up to own* the build system so far. Things may have changed; by all means,
fork, do the work and send pull request.

When I say "own", I mean someone actually being there we can count on to
do the work for releases. Over years, we've seen people come, contribute
code, and disappear. Contributions are certainly welcome, but the big ones
are also additional maintenance baggage we end up carrying as we are moving
on.

—
Reply to this email directly or view it on GitHub.

[aleks-f]

idle, closing