Re: [agtk-devel] What version of xerces-c to build on linux

[Haejoong L. <hae...@ld...>]

On Thu, Sep 23, 2004 at 01:40:45PM +1000, Steve Cassidy wrote:
> 
> it doesn't work without LD_LIBRARY_PATH being set, presumably some
> other magic is needed on windows. There seems little need for this
> since you know where the .so files are installed (or at least
> where they were) and can look there and load the files
> via a direct path. dlopen will take an absolute path
> name and just load the file rather than having to search
> LD_LIBRARY_PATH.  Can I suggest the code be changed to try
> loading from the known location, then backing off to the current
> strategy if this fails.  I'm willing to try making this change if
> there is support.

On Windows, executables and DLLs are searched through the paths defined
in the %PATH% variable.

I think what you suggested is a good thing in general.  So, why not?
I'll be there to support you.  By the way, what kind of support should I
expect?  I see this involves a little bit of coding in the agfio code,
and modifications in the configuration system.  I wonder how you would
like to handle it for Windows, especially with MSVC, for which we don't
have any source configuration mechanism.

Also, I suggest that you use the Devel-2_1 branch for the development of
new features, since I'm doing only bug fixes for the Toward-2_0 branch.

> I note that the install location of each plugin shared library is
> written in the Makefile.am in the plugin directory. Is there an
> automake way of forcing this from above so that we can rely on
> the value rather than hoping that plugin dirs conform?

I'm not sure if I understand it.  The ${prefix} variable in
${prefix}/lib/ag is not enough?

> On a different note, what measures are in place to ensure consistent
> handling of character encodings through different file formats?
> Looking at the CAG format I can't see that it would ensure
> consistent output of unicode strings. I see that internally things
> use the C++ string type, has there been any thought to using wstring 
> instead? This is clearly an issue if something like CAG is supposed to 
> be an alternative to the XML format.

Honestly, I need to learn more about this stuff.  I have been using the
CAG format successfully in production this year.  The data was in
English, so no special care was necessary.  I'm now getting some Arabic
and Chinese data, whose encodings are UTF-8 and GB2312 respectively, and
we'll see what happens.

> It also looks like plain char *
> strings are being used in the scripting interface. It seems a shame to 
> close the door on using non-ascii encodings in this day and age.

Does this imply that AGLIB is incapable of handling non-ascii data?
AGLIB with AG XML format has been successfully used for Arabic and
Chinese projects.  Please enlighten me if I'm missing something.

Thanks,
-Haejoong