Hi David,
I'd vote for first option, but for this we should know
for sure what is the official extension for objects in
GCC OMF mode.
In os2gcc the "gap" between a.out and OMF types are wide and clear,
and
so must be
Is just a matter to know the whole picture and apply differences
properly
Is not a bug in -Zomf mode
As other gcc versions, in os2gcc "native" extensions are:
- .o for objects
- .a for libraries
in both a.out and OMF types
... unless we change extensions
In os2gcc OMF type are usual to use, as I presented examples of other
OS/2 projects:
- .obj for objects
- .lib for libraries
So in Harbour we try to force some alien extension instead
of .o which is the default extension in both OMF and a.out
modes.
The problem I see here is a lack of sync in hbmk2.prg between phases:
- .c compiling. Is using default .o because are not using our own set
cObjExt := ".obj"
- linking. Is using our own set cObjExt := ".obj"
but as you briefly expose, is a matter of technical facts in hbmk2.prg
which are not using "-o " in "hbmk2: C compiler command:"
Solution is clear: sync use of object extension in both phases
I know. However I don't like this approach. Speaking
of both Harbour build and hbmk2, we use the default
extensions for all supported compilers.
For some reason this was violated by using .obj for
gccomf. Not being an OS/2 user this wasn't apparent
to me, I used what I saw.
Using non-default extensions have some drawbacks,
since you need tell each tool your extension of choice.
In case of gcc, this is -o, however in this mode,
you lose the option to build multiple .c input files
at one pass. Which in turn makes performance much
worse in certain cases. Plus it introduces an exception
in both hbmk2 and Harbour build. Latter isn't affected
too much as it doesn't use optimized calls to compiler
using multiple inputs, but in hbmk2 this would need
some extra logic to handle this exception case.
If you set in OMF:
cObjExt := ".o"
then it will be equal to "native" object extension .o which is not
specified in .c compiling phase
This is what I'll do.
If you set in OMF:
cObjExt := ".obj"
then you must to use cObjExt in .c compiling phase too
As I understand, cObjExt in hbmk2.prg and OBJ_EXT in "make" are to set
our own extensions, and they must be used in any phase
And yes, you can use .o as object extension in OMF too, but try to
follow most of OS/2 projects style using .obj and .lib in OMF
For a peace of mind and "standardness", I vote to follow
compiler defaults, whatever these are. No need to fight
what GCC developers have decided on. With the case of .obj,
we're trying to mimic other OS/2 compilers doesn't seem like
a good idea.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
