Anything that simplifies the build is goodness. My vote is for getting rid of libtool.
--JYL > If you are building Metakit on anything but the usual quad or so of > most common platforms, any of C++, Python, or Tcl - could you please > help decide what to do? > > > > YES OR NO: get rid of libtool in the MK build process? > > WHY: less fighting, drop dependency on libtool, which has changed over > the years. > > WHY NOT: may require some work to build for special platforms (AIX? > HPUX?) > > HOW: switch to "gcc -shared", with a few refinements to make it work on > Mac OS X and such. These refinements can be added to the > unix/configure.in logic, autoconf has sufficient capability to cover > most cases, I think. > > WINDOWS: no change, when built with MSVC 6 (I just checked in a MSVC > 7.0 version, btw). No change with mingw either, since "-shared" does > the right thing nowadays. > > TCL: probably not affected, it has its own configure logic. > > PYTHON: probably not affected, it is moving to distutils. > > > > Your votes and opinions please... > > -jcw > > PS. In fact, I'd love to throw out all of make and autoconf, if I knew > how to create an effective distro without them (Python is furthest > along in that area, clearly, with its distutils). Make is a brilliant > concept, but even that makes little sense when it's about deploying and > compiling a tested distribution - once. IMO the only strong case for > autoconf + make nowadays, is that everyone in OSS-land is used to the > "configure; make; make install" salute. > > _____________________________________________ > Metakit mailing list - [EMAIL PROTECTED] > http://www.equi4.com/mailman/listinfo/metakit _____________________________________________ Metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
