Regarding Poco build system #29

Closed
ghost opened this Issue Dec 9, 2012 · 12 comments

Comments

Projects
None yet
3 participants
@ghost

ghost commented Dec 9, 2012

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

This comment has been minimized.

Show comment
Hide comment
@aleks-f

aleks-f Dec 9, 2012

Member

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.

Member

aleks-f commented Dec 9, 2012

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Dec 9, 2012

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 commented Dec 9, 2012

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Dec 9, 2012

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

Found out it's for NumericString implementation. Sorry.

ghost commented Dec 9, 2012

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

This comment has been minimized.

Show comment
Hide comment
@aleks-f

aleks-f Dec 9, 2012

Member

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.

Member

aleks-f commented Dec 9, 2012

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

This comment has been minimized.

Show comment
Hide comment
@aleks-f

aleks-f Dec 9, 2012

Member

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.

Member

aleks-f commented Dec 9, 2012

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

This comment has been minimized.

Show comment
Hide comment
@patrickjwhite

patrickjwhite Dec 15, 2012

Contributor

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.

Contributor

patrickjwhite commented Dec 15, 2012

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

This comment has been minimized.

Show comment
Hide comment
@aleks-f

aleks-f Dec 15, 2012

Member

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.
Member

aleks-f commented Dec 15, 2012

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Dec 16, 2012

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).

ghost commented Dec 16, 2012

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

This comment has been minimized.

Show comment
Hide comment
@aleks-f

aleks-f Dec 16, 2012

Member

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.

Member

aleks-f commented Dec 16, 2012

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

This comment has been minimized.

Show comment
Hide comment
@aleks-f

aleks-f Dec 16, 2012

Member

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.

Member

aleks-f commented Dec 16, 2012

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

This comment has been minimized.

Show comment
Hide comment
@RangelReale

RangelReale Dec 16, 2012

Contributor

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.

Contributor

RangelReale commented Dec 16, 2012

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

This comment has been minimized.

Show comment
Hide comment
@aleks-f

aleks-f May 1, 2014

Member

idle, closing

Member

aleks-f commented May 1, 2014

idle, closing

@aleks-f aleks-f closed this May 1, 2014

obiltschnig pushed a commit that referenced this issue Mar 31, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment