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]
