apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: Time for APR 2.0?
Date Fri, 28 Aug 2015 14:24:18 GMT
Am 28.08.2015 um 15:20 schrieb Michael Schlenker:
> Am 28.08.2015 um 01:53 schrieb Noel Butler:
>>
>>
>>> That's why I want us to extend cmake to do the unix build as well.
>>>
>>>
>>>
>>>
>>>
>> The biggest bitch I here from *nix/bsd system admins  everywhere is
>> cmake, the largest bitch is people know how to use --with-foo --with-bar
>>   now after decades, THEY, the people you expect to use your software,
>> have to learn it no longer works that way, I know of multinationals
>> change software because of cmake, I've seen a well known large
>> international issue a policy that they will remain on old unsupported
>> versions of mysql because they moved to cmake.
>>
>> autoconf et al, might be ol school, but every man, woman, and dog knows
>> and understands it,
>
> Knows yes. Understands autoconf/m4/libtool in depth: Highly in doubt
> about that claim, the vast amount of cargo culted libtool/m4/configure
> macros floating around speaks against it.
>
> Autoconf/libtool is great when it works. But if it does not, you are in
> for a world of pain.
>
> CMake is different yes, and has quite a few warts of its own, but it is
> vastly simpler to understand and reason about than libtool/configure/etc.
>
> Regarding cmake as a solution to get rid of those dsp/dsw files:
>
> YES!
>
> Cmake provided project/nmake/make files have one issue though, which
> might not be obvious to someone never using cmake: Those depend on cmake
> for a variety of tasks (e.g. install tasks are often done by invoking
> some 'cmake -E' stuff and so on, via extra build tasks).

I want to strengthen this point: IMHO very similar to configure, using 
cmake as a generator without having cmake on the system where you run 
the build likely will not work. You can't just run it at release time, 
generate nmake or vcxproj files and the consumer only uses MSVC to do 
the build. The end user will need to run cmake on his system. I have 
seen cmake calls in the generated nmake files, but also full absolute 
paths to extracted source files etc. in the generated vcxproj files. So 
those can't be generated at release time.

I'm not terribly experienced with cmake though and maybe it has a more 
friendly generation mode.

Despite those problems, I don't know of a better way to maintain the 
build artefacts we need to ensure windows platform support.

> So if one killed off the dsp/dsw files, it gets harder to adjust and
> tweak the created projects in VisualStudio, you need to fix the CMake
> file and recreate the project file. Which isn't that much different to
> the way autoconf works with configure.in etc.
>
> CMake does a few things nicer than libtool/autoconf, especially when you
> are NOT a linux distro builder. For example it doesn't force you to use
> -rpath everywhere like libtool does, can create installers/rpms etc. out
> of the box and has various other conveniences.
>
> But to make it really good, there should be some standard FindAPR.cmake
> file provided (and sent to kitware for inclusion), to make it easier for
> packages using apr to detect the bits, pieces and parts.

Rainer

Mime
View raw message