[fdo-internals] CMake build fixes (Re: FDO 3.7 beta2 timeframe)
Johan Van de Wauw
johan.vandewauw at gmail.com
Mon Oct 15 01:15:40 PDT 2012
I'm extremely busy this week but I may have a look next week to the other
issues you're talking about.
Anyway: since the autotools build is not using sonames anywhere it should
be dropped here for every library. Better not to have a soname than one
that is not correct or that is not used.
The version number of FDO should then be added to all public libraries; in
the same way as it is done for the auto* build now. But you have to do this
manually; AFAIK there is no switch in cmake that corresponds to libtool
But before rushing to making these changes: what is the original reason
that we have two build systems? We could also consider changing the
autotools build to optionally use dynamic libraries...
On Mon, Oct 15, 2012 at 7:56 AM, Jackie Ng <jumpinjackie at gmail.com> wrote:
> Hi Johan,
> Now that MapGuide 2.4 is out the door, I've had time to take another look
> My question is should this SONAME omission be done for all FDO shared
> libraries? Or just the "public" ones that would be linked by MapGuide
> (libFDO, libExpressionEngine)?
> I also noticed that the file listing of a cmake build differs from an
> automake one. There are some libs that are being created as shared
> libraries instead of static ones. Doing a SHARED -> STATIC add_library
> replacement on the applicable CMakeLists.txt caused a whole load of linker
> errors. Obviously something extra needs to be done here.
> For packaging purposes, the cmake build should be producing the same set of
> output files as the automake one.
> Got any extra notes to share?
> - Jackie
> View this message in context:
> Sent from the FDO Internals mailing list archive at Nabble.com.
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fdo-internals