Re: XTL patches

[Jose Orlando Pereira <jop@di.uminho.pt>]

Asger Alstrup Nielsen wrote:
> 
> I see two choices for the technical aspect:
> 
> 1) The LyX code uses a "config.h" file which defines what is available
> and what is not.
> This file is built on the basis of a configure script which runs a few
> short test prorgams to determine the systems capabilities.
> A similar approach is used in many other projects, and I think it would
> fit nicely into the XTL setting.
> 
> 2) An alternative approach is to use a "smart" config.h file which at
> compile time uses a series of #ifdefs to determine the system that is
> used. I.e. #ifdef __GCC__ and so on. This approach is used by the SGI
> STL implementation, and has the advantage that it does not require the
> existance of a shell to run the configure script in.
> 
> There is no shell on some platforms, including Windows and Mac.
> 
> Of course a hybrid approach is also possible, but for starters, I think
> the 2nd approach is the best because it's the easiest to get started
> with, and it might turn out to be sufficient.
 
I agree that the smart config.h is the best option. In fact, there used
to be a config.h in include/xtl, but after I started using byteswap
macros from glibc I removed it as it was no longer being needed. 
 
> Now, one thing is to determine which technical approach is the best,
> another is to realize it.  In this context, I think the best way is to
> use some of the existing open source communication channels to get a
> broad selection of testers.
> I.e. go ask specifically for help to make XTL more portable.

There has not been much feedback, but I'll continue to publicize it
on Freshmeat as I improve it. I currently have some minor patches
pending, and after integrating your previous contribution I'll release
a new version soon.
 
> Such a request for help would have to be backed up by active support to
> cater for, evaluate, incorporate, and critize any comments or questions
> that inevitably would come.
> That part of the problem should not be underestimated, and I'm afraid
> that I can't volunteer much time for this to help you out.
> 
> Finally, you have to be ready to polute the source code with some ugly
> stuff to support brain-dead compilers and systems, but it's seems you
> ready to do that, which I think is a wise decision.

Old compilers will be a problem. XTL was started almost 4 years ago,
but I could not finish it until egcs caught up with C++ spec in
regard to templates.

I will be glad to apply patches in order to improve portability.
However, I'd prefer that in doing so XTL gets closer to the ISO
spec and not further away. As such, accomodating old compilers
should be done by opting out some features and not by crippling
the design for people using modern compilers. I believe this is
what people at SGI have done with the STL.

I also don't know what is the status of other compilers, as I
use only Linux. Could you send the "ugly patches" for Win32 you
mentioned in your previous message, so I can get an idea of
what features are causing problems?

> > > I know the LyX team is considering to use the XTL library for internal
> > > stuff in LyX. In order for this to happen, it has to be fairly portable.
> >
> > That is news to me. Has it been discussed in a public forum?
> 
> Only shortly on the LyX developers mailing list. (I'm part of the LyX
> development team.)
> We have a need for a means of communication between the GUI and the
> kernel. We are moving towards a very clean separation of the kernel and
> the GUI, and that requires information to travel across this boundary.
> This communication should be clean and efficient, and it seems that XTL
> might fit these requirements nicely.

I see. The predecessor of XTL, briefly mentioned in the documentation,
was designed precisely as glue between and an application kernel and
its GUI. Currently I'm using it in communication protocols where
reducing externalization overhead is a big issue.

> P.S. I'm subscribed to the XTL mailing list, and you are free to forward
> this if you want to.

Done.

-- 
Jose Orlando Pereira
* mailto:jop@di.uminho.pt * http://gsd.di.uminho.pt/~jop *