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

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.

Michael

-- 
Michael Schlenker
Senior Software Engineer

CONTACT Software GmbH           Tel.:   +49 (421) 20153-80
Wiener Straße 1-3               Fax:    +49 (421) 20153-41
28359 Bremen
E-Mail: michael.schlen...@contact-software.com
http://www.contact-software.com/

Registered office: Bremen, Germany
Managing directors: Karl Heinz Zachries, Ralf Holtgrefe
Court of register: Amtsgericht Bremen HRB 1321

Reply via email to