Murray Cumming wrote: > > On Wed, 2001-10-10 at 22:44, D. Stimits wrote: > > "Jason E. Stewart" wrote: > > > > > > "Mark Weaver" <[EMAIL PROTECTED]> writes: > > > > > > > I would find this change extremely welcome. The current random header file > > > > location is annoying, to put it mildly, plus prone to potential collisions. > > > > > > > > This would seem to be the right place to post, but finding an active > > > > committer here willing to take on changes seems to be rather a challenge! > > > > > > You should first take a look at the work the Murray has done. This > > > should address many of these issues. > > > > > > jas. > > > > > > ------------------------------------------------------------------------ > > > Part 1.2Type: message/rfc822 > > > > Having include files installed as shown there is a major improvement, > > e.g., to /usr/include/xercesc/. There are other issues I'm interested in > > in addition to this, for simplification of config without setting > > environment variables. But in either case, is it possible to get > > something merged into the official distribution? Xerces is a major > > barrier when it comes to projects that are to be distributed in source > > form and then compiled by average Linux users (versus developers). Being > > able to install Xerces headers would remove the XERCESCROOT setting > > quite nicely, but there are other specifications that simplification > > would also aid. > > > > I hear a lot of people shout about the use of automake/autoconf/libtool > > for cross platform configuration, but when doing C++, autoconf and > > friends are basically broken; mix C and C++, those tools are a disaster. > > You'll have to give more information to convince us of that point of > view. The autotools are widely used, successfully.
I was on the autoconf/automake devel lists for a while, pointed out some problems, they were being "addressed", but only partial solutions were complete. I then got tired of all the email spam mining and had to leave the list. The bugs were found while trying to convert a mixed C/C++ project. Some software configurations might not run into the bugs found, but they were fatal to my projects, and until autoconf/automake improves drastically with C++, I won't use it there. On the other hand, if autoconf/automake were used on xerces-c successfully, I wouldn't argue. I'd like it. But I'm skeptical that complete conversion to autoconf/automake would be possible within the near future, it would be a long project, with a lot of time for debugging required. Despite the presence of some autoconf/automake files within Xerces already, it is incomplete. runConfigure is required, environment variables are required, much end user intervention is required. Relative to the scale of Xerces, I'm not saying that a lot has not been accomplished with configuration of a complex system, but it is not sufficient for success with average people. > > > So I am not suggesting conversion to some big configuration tool, but > > even the basic Makefiles involved tend to be a barrier when writing > > packages that will depend upon Xerces. > > I have found it to be relatively simple to build packages that depend on > Xerces-C. For instance, > >http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/bakery/bakery_example_xml/configure.in?rev=HEAD&content-type=text/vnd.viewcvs-markup > > The main problem is that it's not yet easy to package it, largely > because the API is not stable. I'm not sure how that applies to items like default values for prefix and other installation values. In the case of having to set XERCESCROOT, I would think the software should be able to figure out where its own location is without manual intervention. Assuming this is somehow connected to the prefix value of install paths, it isn't appropriate naming or default behavior. I really am not trying to be a pain in the butt, though I probably am. But after feedback from users of a prior project, which is being replaced with a "next generation" product, I know without hesitation that this will become a serious issue to acceptance. We've already decided to require Xerces, what we can't decide on is whether non-technical types will be able to configure it without all kinds of special steps on the development side which will end up making things less modular. D. Stimits, [EMAIL PROTECTED] > > > Some simple things could be done, > > such as offering sane default values for some unset variables. Xerces is > > an amazing piece of work, I'm surprised that configuration and > > installation is so far behind the actual code. > > If users get frustrated > > by it, and can't or won't use it, then it does no good for anyone. > > > > D. Stimits, [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- > Murray Cumming > [EMAIL PROTECTED] > www.murrayc.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
