Hi Marc,
Thanks for submitting your changes.
>
> I managed to port xml4c2_3_1 and ICU to SGI IRIX 6.5.5 using SGI
> MIPSpro C++ 7.3 and 7.2.1 generating 32 bit objects.
>
I just finished merging in the changes that you submitted to make it
work under IRIX. The submitted changes were for XML4C 2.3.1, but they
were easy enough to merge. Hopefully, I have not missed any significant
ones.
Now, as I do not have access to a SGI machine, I have not tested these
changes. Could you please extract the sources from the repository and
give it a try.
For a start, please try using the native transcoding option rather
than ICU and use 'inmem' message loading.
What remains is testing and changes to documentation.
The current Xerces-C code works with ICU 1.3.1 under NT, Solaris 2.6,
AIX 4.1.5 +, HPUX 10.20 and HPUX 11.0 besides RedHat 6.0.
Your changes for ICU 1.2.5 (bundled with XML4C 2.3.1) have been
forwarded to the ICU team.
I have mentioned your name in the commit message as the contributer
of this port. If this is not acceptable, please let us know and we
will remove your name from all the files.
In general, all contributers please indicate your preference about
including your name/email address in the attribution.
> Actually, in order to make xml4c I had to cheat a little:
> When the SGI compilers encounter templates, they emit information in
> the object file, and in an associated .ii file to help the prelinker
> determine which files are responsible for instantiating the various
> template entities referenced in a set of object files.
> These .ii files are located in a directory ii_files which is created
> in the directory where the object files are written (which usually is
> the directory where the .cpp files are).
> These .ii files contain absolute pathnames to their corresponding
> object files.
> Now, you are using an /obj directory where all the object files are
> copied to. Unfortunately it is not possible to also copy the .ii files
> to the /obj directory. Due to the absolute filenames the prelinker
> cannot find the corresponding object file, and a fatal error occurs.
> I got around this problem by compiling every source file twice; the
> second compile output goes directly to the /obj directory -- the .ii
> files inclusive. This of course renders the cp in the Makefile
> superfluous.
> In Makefile.incl line 61 I created a new variable OBJ_OUT which is
> used in lines 203 and 207.
> This is not very elegant and doubles compile time.
> Actually, I don't really understand why you use the /obj directory at
> all. Building the library would be just as easy when the object files
> were left where they were compiled. The pathnames are all known; I
> can't really see what the /obj directory is needed for.
For now, I have merged in the double compilation of the .o files.
The goal (not achieved yet completely) is to have the object files
generated directly in a separate directory from the sources. And that
is the reason why we have XERCESCROOT/obj directory.
As you correctly mentioned, we currently generate the .o files in the
same directory as the source files and then copy them over to the obj
directory. So there is that extra copy of .o files sitting.
What I would like to see happen is to directly generate the .o files
in the obj directory. I have not checked yet if specifying somthing
like this works with 'gmake'.
.cpp$(OBJDIR)/.o:
$(CC) -c $(COMPILEFLAGS) -o $@ $<
The makefiles do not have the dependency list in them and all compilers
do not give you an option to generate the dependency list. Hence, we
currently have in the makefile commands equivalent to:
.cpp.o:
$(CC) -c $(COMPILEFLAGS) -o $@ $<
$(CP) theObjectFiles to theTopLevelObjectDir
> I would like to make some changes in the xml4c sources. Perhaps you
> could let me know the approx. date of the next relase so that I don't
> have to do this twice.
The next binary release should happen in less than two weeks time.
> General Notes:
> 1.
> class DOM_Attr is kind of useless as there is no way to convert from a
> DOM_Node
- snip -
> 2. DOM NodeEnumerator is missing
> 3. DOM AttributeList is missing
> If (2) and (3) were implemented, (1) wouldn't be a problem.
> 4. transcoding: I wrote a little helper method that saves tons of
> code:
>
- snip -
> 5. Provided a compiler is used that supports auto_ptr, instantiating a
> parser can be done like this:
- snip -
We are looking into these suggestions and will respond separately.
rahul
[EMAIL PROTECTED]
