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. Regards, Graham --
smime.p7s
Description: S/MIME cryptographic signature
