httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: Discuss: Dropping dsw/dsp files
Date Sat, 21 Jan 2012 00:01:54 GMT
On 20 Jan 2012, at 10:32 PM, Gregg L. Smith wrote:

> True, but there are reasons I prefer the GUI, biggest is where one runs into trouble
during a compile. I can rebuild any specific problem project/s, remove buildbin dependency
from the installbin project, and when I have hammered out the specific problems, use said
installbin to just copy the files into place.
> Good example is recent APR-Util 1.4.1 and the static lib not compiling w/ crypto. I was
able to compile all but the few things linked to the static lib, remove the crypto switch
in apu.hw, then built the static lib and the things like ab and abs that linked to it, none
needed apr_crypto anyway. Not such an easy task to do via makefile.
> New people to the game also prefer the GUI, after all, why do we have Windows (ok, KDE.
XServer, Gnome, same in the *nix world these days)?

I use Eclipse extensively for development on Unix platforms[1] in a GUI environment, and the
very first thing I do on any C/C++ project in Eclipse is turn off any Eclipse-based Makefile
generation - Makefile's are the job of autoconf/automake[2], Eclipse to me has no business
fiddling with it. It's the same when I work in Java, the build is maven's job, not Eclipse's.
Fortunately, Eclipse is reasonably sensible when it comes to build tools, and will step out
of the way gracefully if asked. Fortunately too, maven has plugins that will synchronise the
world of maven with Eclipse, and keep things sane.

The reason this is important is the world of pain that you describe above in the Windows world,
a host of fundamentally different development platforms, each of which completely is incompatible
with the next. To me, a world without autoconf/automake, and a world without maven is just
a world of pain - you need a dedicated tool that says "I do portable builds, leave it to me".
I believe these exist in the Windows world, and could potentially generate the Makefiles and/or
project files as needed by each environment. Can this not be considered?

A note on portability - people often just assume portability means "it works on Unix and Windows",
but in reality there is also the axis of operating system versions too. Code should ideally
be portable across versions of operating systems too where practical, so 2k/XP/Vista/7/etc
are all kept practically supportable within the same code base without pain.

[1] By "Unix", I mean MacOSX and (Redhat) Linux in my case, obviously there are others.
[2] I recognise we use autoconf, but don't use automake, and have never understood why. Autoconf
meshes with automake, which meshes with libtool, and allows you to do loadable modules out
the box with no angst and drama. For those in the RPM world, rpmbuild knows how to mesh with
all of this too, so build differences between 32 bit and 64 bit, different architectures etc,
are just Not My Problem(TM), which is how it should be. I understand Debian packaging is similar.


View raw message