Re: Apache-Xerces on Mac

[James Berry <jb...@criticalpath.com>]

Hi Ronny,

(I've copied the Xerces list with my reply to help enhance knowledge of
others who may be lurking...)

Thanks for the email. I'll try to answer your questions. Please don't
hesitate to call if you need more than this.

In general, there should be no compatibility problems between the Xerces Mac
implementation and the CodeWarrior 5.0 development environment, with the
following exceptions:

    (1) The Mac OS "Universal" headers/libraries that come with CW 5.0 are
not current. The Xerces code uses new definitions (in both the headers and
in the stub libraries that they link with) which can only come by updating
against new headers for this code.

    (2) You don't mention this as a problem, but there's a slight chance
that the Xerces code relies on C++ language features or library semantics
that weren't properly represented in CW 5.0.

I believe that (1) above will be your only problem; fixing it should fix all
the problems you discuss below. To do so, you need to get the latest
Universal headers release from the Apple Website, and either replace the
existing from your CW 5.0 directory, or create a new directory and update
the CW project access paths to point to it.

You mention Carbon and Carbon lib a couple of times below, so I'll try to
straighten you out. As long as you don't set the TARGET_API_MAC_CARBON
define in your project, the Xerces code will not try to use or link against
any routines that require you to link against the Carbon library or Carbon
stub library.

But to reiterate what I said above, this code does require a
_build_environment_ with current headers and stub libraries. An example is
the call(s) to FSMakeFSRefUnicode, to pick one out that you name below. This
routine is available in Mac OS Systems 9.0 and later (if I recall correctly,
or maybe even back to 8.6). It is "published" in the current Universal
Headers and by the InterfaceLib stub that ship with them, but wasn't in
earlier headers and/or stub libraries.

In order to resolve link-time issues, it is necessary only to link against
the updated InterfaceLib stub that exports this routine.  Note that this
does not require that the code be run on an OS that actually implements this
routine. The Xerces Mac platform code is very careful to do the proper
tvector tests to verify that the functionality is actually present,
_at_run_time_, before using it. And in this case, it will fall-back to other
routines if it's not there.

Summary: if you can update the _development_time_ support headers and stub
libraries to current version, you ought to be able to build this code
without any changes. You "ought" to be able to do this in a way that has
little impact on the rest of your build process & dependencies.

Please let me know where I'm wrong ;)

-jdb

On 3/1/01 5:28 PM, "Ronny Ashar" <ro...@avid.com> wrote:

> Hi James,
> 
> I'm working on incorporating some XML parsing functionality in Avid's
> main product. For this we would like to use Apache-Xerces C++ sources.
> On Windows I could easily integrate the Xerces libraries.
> 
> On the Mac, your Perl utility for shortening file-names was helpful and
> I was very glad to find the Xerces.mcp.xml that you have provided.
> Initially, I created a project with it and built using CodeWarrior 6 and
> that worked fine. However to be consistent with our main product's
> development environment I need to be building with CodeWarrior 5 and
> with no Carbon.lib dependency(even using the carbon.lib stub is not an
> option for us since that could cause sideeffects/conflicts in the main
> product) on MacOS 9.1 and up. I'm trying to build Xerces Lib Classic
> this way and running into link errors.
> 
> I attempted to ifdef some of the fork calls - FSGetForkPosition and
> others - since those would get invoked only if gHasHFSPlusAPIs is on and
> I'll be sure to set that to false. But I still encounter linking
> troubles owing to calls to FSMakeFSRefUnicode, FSGetCatalogInfo etc. And
> those calls are in methods such as XMLParsePathToFSRef_Classic - which
> cannot be ifdefd cause I think they would be required while opening a
> file etc.
> 
> Coming from the Windows world I know very little about Macintosh
> libraries. But I noticed that in your readme you've mentioned that you
> are using the new FSRef calls and Unicode names whenever possible. I
> guess those are not supported in non-carbon environments? And so my best
> bet would be to sweep through MacOSPlatformUtils.cpp and other files in
> the MacOS directory and attempt to find old-OS equivalents for those
> methods? Or is there a better/smarter way to handle this?
> 
> Any insights/pointers you can send will be much appreciated.
> 
> Thanks,
> 
> Ronny Ashar
> Senior Software Engineer
> Avid Technology
> 
> 

--
/**********************************
 James D. Berry
 mailto:jberry@criticalpath.com
 vox:503.265.1213 fax:503.222.3020
 **********************************/