On Sun, Jun 25, 2006 at 05:29:07PM -0700, [EMAIL PROTECTED] wrote:
Sounds like lots of good stuff in the new 4.5 release, I'm looking
forward to finding the time to work with it. :) For now though, I
have a bunch of questions and comments about future build
environments:
> * The build environment in general is annoying. As described, there
> was an effort in this release to support Unix and Win32 from the
> same makefiles which, while a bit clever, likely irritated more
> Unix developers than excited Win32 developers. In addition, the
> Unix configure script is weak, overly reliant on the context from
> a properly built Tcl installation, and the makefiles rely too much
> on GNU make features. Creating a proper Unix configure script which
> creates proper Makefiles is planned for the next release along with
> a possible shift in the Win32 strategy (see next note).
Rather than shifting Windows builds Msys-based Unix-style
configure/make, and improving the configure scripts, would it make
more sense to just junk the rather baroque and kludgy configure/make
stuff and switch to a 100% Tcl based build process?
I've no idea how useful they are, but here are a bunch of Tcl-based
tools intended to replace make (and hopefully also configure). Has
anyone here tried any of them?
Make replacements in Tcl:
bras: http://developer.berlios.de/projects/bras/
http://pifpafpuf.de/
tmk: http://www.tmk-site.org/
smake: http://wiki.tcl.tk/9741
others: http://wiki.tcl.tk/12592
Also Aardvark in Apache Rivet:
http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/d1f63b58008f6aa6/
http://openacs.org/forums/message-view?message_id=203781
Compare to SCons in Python: http://www.scons.org/
Way back in 2004, I was planning to eventually try Bras (as it claimed
to be the most powerful, and had some good reviews on comp.lan.tcl
c. 2002), with an eye towards having the SAME build environment on
both Windows and Linux. But then the C coding I was doing wound down,
so I never got around to that...
> Changes to the Build Process:
> * AOLserver does not compile with the latest Visual C++ 2005 from
> Microsoft. While some of the new safety and security features in
Why not? What would it take to make AOLserver build correctly with
VC++ 2005?
> increasingly irritating. As such, we will be exploring a shift to
> Msys-based Win32 build in the next release, enabling us to utilize
> our Unix-based development approach while still allowing AOLserver
> to run against native Win32 libraries. Feedback is appreciaated.
Using Msys on Win32 instead of VC++ sounds mostly fine to me, but it
would be nice to support both. (I think Tcl does.)
Is there any reason why someone would NEED to use VC++ rather than
Msys to build AOLserver? If, say, they want to write an AOLserver
module which uses a C++ DLL pre-built using VC++? Aren't there
supposed to be name-mangling issues with C++ that prevent you from
mixing code built with different compilers, or something like that?
> * On Win32, the legacy Visual Studio build directories have been
> removed entirely has their maintenance proved irritating and
> complicated.
Ditching those definitely makes sense to me. I used them to build
AOLserver with an Visual C++ 6.0, and while they can be made to work,
they WERE quite klunky and annoying.
I was actually surprised just how clumsy VC++'s default build
environment was. It literally felt like something put together by and
for people who were afraid to program and had never heard of
refactoring - a strange feeling in a product targetted at professional
C++ coders.
I later adapted Dossy's build.tcl script solely for building nsopenssl
on Windows using Microsoft's free (as in beer) VC++ 2003 compiler.
That script is clearly a quick hack and definitely not what I'd
recommend as the main build tool, but working with it wasn't bad.
--
Andrew Piskorski <[EMAIL PROTECTED]>
http://www.piskorski.com/
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
