On 2/24/03 11:26 AM, "Tinny Ng" <[EMAIL PROTECTED]> wrote: > James, > >> - A migration to a more strict autoconf based configuration system ... >> - Provide meaningful defaults so that no parameterization is required ... >> - Coalesce platform support as much as possible to eliminate >> redundancy..... >> - Research (and hopefully implement) ways to eliminate need for >> XERCESROOT. > > I think I like the idea. If we look at ICU configuration, their > runConfigureICU is very thin and simple. I believe we can have similar > design in Xerces-C++. > >> - configure once for all of Xerces, not separately in multiple >> directories. > For multiple directories, I think you mean "src", "samples", and "tests", > right?
Yes. > This can be challenging, as the option used to build the DLL can be quite > different from those used to build the samples/tests. Hmmm. I'll have to think about what that means, particularly as I'm not as familiar with the Windows build. The options to runConfigure are typically platform, compilers, threading, etc. What options tend to change between DLL and >In addition, to > allow users building the samples from the binary distribution (where the > directory "src" does not exist), we may need a "configure" in multiple > places... Though we might be able to handle that by detecting whether the src directory exists in the distribution... -jdb > > Tinny > > ----- Original Message ----- > From: "James Berry" <[EMAIL PROTECTED]> > To: "Xerces C Dev" <[EMAIL PROTECTED]> > Sent: Sunday, February 23, 2003 11:47 AM > Subject: Request for Input: Xerces Configuration/Build System and Ports > > >> After spending the evening last night in traipsing through the Xerces > build >> and configuration system, I have a renewed sense of purpose over what I > feel >> is a problem that should be addressed. >> >> To put it (perhaps rather too) bluntly, the Xerces build and configuration >> system is a tangled mess, hard to maintain, and hard to port to new >> platforms. I'll name at least the following problems: >> >> - Does not use standard open source configuration/build paradigm: >> ./configure; make >> >> - runConfigure requires parameters it could usually discover on its own. >> >> - There are separate runConfigure programs for the library, samples, >> and tests, where one alone would probably do. >> >> - Each supported platform requires a new set of "platform" files while >> most are almost identical. >> >> - Use of XERCESROOT is required >> >> The net result of these issues is that: >> >> - It is daunting to port Xerces to a new platform. >> >> - Xerces is not as well accepted in the open source community because >> of its non-standard configuration idiom. >> >> - Maintenance of the platform specific ports is tedious and haphazard >> because there is so much code redundancy. >> >> - Use of XERCESROOT requires environment changes that limit ease of use >> and adoption. >> >> All this said, I propose the following: >> >> - A migration to a more strict autoconf based configuration system >> (Xerces actually uses it at a low level but also for no apparent >> reason layers runConfigure on top of it). >> >> - Provide meaningful defaults so that no parameterization is required >> for the most common cases. >> >> - configure once for all of Xerces, not separately in multiple > directories. >> >> - Coalesce platform support as much as possible to eliminate redundancy. >> >> - Research (and hopefully implement) ways to eliminate need for >> XERCESROOT. >> >> I'd like to get comment on this proposal: >> >> - Are these my problems only, or do others share the same concerns? >> >> - Would a solution as defined above be acceptable? >> >> - Are there critical issues with autoconf on specific platforms? >> >> - Historical insight on why we got to where we are? >> >> If consensus is reached, an implementation might go like this: >> >> (1) Begin to build a new autoconf based configuration system in parallel >> with existing system. >> >> (2) In an evolutionary fashion, as the new system supports new platforms >> the historical stuff will be deprecated. >> >> (3) This will require input from porters to retest, and submit new hints, >> for various platforms. Platforms for which no community steps forward >> to adopt the new will likely become unsupportable over time. >> >> Discussion? >> >> James. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
