Viktor:

It's not a different compiler but the same in a different mode
altogether, and/or different version.

Yes, and it's a big difference, since you added a new "dimension"
to the existing set of settings, while I've only extended existing
dimensions with a new value.

Do not fool ourselves
HB_COMPILER=gccomf is an "virtual" compiler managed by your HB_COMPILER
structure forced to maintainance in compilers list/cases

You applied this alternative for many reasons, firstly:
- HB_COMPILER structure can do it
- You know how to implement it
- You are worried about "compilers" filenames collision
- You rejected my "new dimension" proposal even it is perfectly controlled

For now HB_COMPILER=gccomf is doing HB_OS2_OMF work


Default mode doesn't work in GCC 4.x. Kinda strange to me,
and this leaves this while discussion rather theoretic.

Is easy to understand, see below

If you mean to check -Zomf inside HB_USER_CFLAGS and act upon
that, it's doable without introducing a new explicit setting,
although it doesn't really change anything on the end-result
side: You've just made the switch hidden.

See below


     --- GCC 4.x
     C:\usr\bin\gccenv.cmd
     set HB_COMPILER=gccomf
     os2-make

These are examples. All of them are meant to reflect "typical"
cases. Not all cases, and not cases to as-is in any setup.
They are meant to give an idea how to start, with the hope that
it works in a "typical" setup.

Is wrong information which must be fixed or droped

I suggest you to use info I included in revision 12630 which cover our
two OS/2 specific cases, replacing HB_OS2_OMF with HB_COMPILER

Updated info: your revision 12639 fixes partially
c:\usr\local433\gccenv.cmd does not exist. User must refer to included
examples to set environment or to use an modified gccenv.cmd, mine is
gccenv433.cmd
Drop that info and preferably include my revision 12630 info, it does
not lead to wrong compiler environment settings and lead easily to OMF use


"longer", "easier". Do you want to compare implementations solely by
number of bytes added? ;)

Is stupid to use that measure   :-)

Finally and most importantly:

I didn't understand your words on autodetection. Since GCC 4.x ONLY
supports gccomf mode, it would be logical to detect this version (by
checking some files which are present in 4.x, but not present in <
4.x), and select gccomf BY DEFAULT in this case. This is just to aid
users. This still allows to select the other mode by setting
HB_COMPILER manually.

[ In case you're expecting that COFF mode will work again in 4.x once
in the future, we could still do autodetection and tune default object
mode depending on GCC version used, but in this case OS/2 users should
decide which should be the preferred object mode. ]

I presented a lot of info and some of them you confirmed when you made
your search

- When gcc was ported to OS/2 it only support a.out type
- Harbour for OS/2 was based in that scenario
- OMF type is native to OS/2
- OS/2 gcc porters/developers added some tools to convert a.out to OMF
"library".a is converted to "library".lib using emxomf.exe
- A lot of OS/2-gcc developers continued work to add support of OMF to
os2gcc. In the path they enhanced many tools and added others
- An "unavoidable" switch was added to specify new alternative: -Zomf
and of course some other necessary values
- OS/2-gcc developers continued trying for OMF for a clear reason: reach
a better scenario than a.out
It was not a vague purpose
- Many of these works were added or made within Innotek OS/2-gcc version
around 2003-2005
Innotek is the same company which created VirtualBox now property of Sun
Some of their developers are OS/2 experts
Mainly of these works are now contained/mantained/available in netlabs.org
- As they were trying to get the best with OMF, they enhanced some tools
to achieve it, for example WL.exe based in WLINK
- For 2005-2007 all work has been done and OMF support reach maturity

- Many OS/2 developers moved to this new scenario: now OS/2 developers
are centered on OS/2 OMF and a.out is legacy

- a.out continue historically by default and -Zomf are unavoidable
Rest of settings for OMF are optional

- As they moved to OMF converted their scripts for OMF using
"unavoidable -Zomf" leaving optionally a.out support as legacy
- They are accustomed to OMF and to use -Zomf does not cause
nuisance

- When gcc4xx arrived they found problem for a.out with emxbind. But who
cares ? They are doing things very well with OMF for years
Just continued using OMF and converted pending scripts from a.out

- Officially os2gcc keep with a.out as default but in practice work is
using OMF
Nobody is worried to change it. Just use unavoidable -Zomf and all is done
They will fix emxbind for gcc4xx ? I do not think so, they are no need
For these reasons are not strange as you think

- They need to "mark" OMF as default in gcc4xx because it fail with
a.out ? No. Just use "unavoidable -Zomf" as they are doing for years
For this reason there are nothing in gcc version files which can be used
for "autodetection". No difference for 4.x or < 4.x

- They will drop a.out ? I do not think so and there are not need. Some
people are happy there still

- And Harbour ? while OS/2 developers moved from a.out to OMF and some
from gcc3xx to gcc4xx, Harbour continued based in a.out and gcc3xx as
only option

Now with our work Harbour for OS/2 moved to where actions are: OS/2 OMF
scenario and newer compiler versions

Using my words of previous message:
-------------------------------
- I repeated, in previous time to do anything with Harbour we need "to
tell Harbour to tell gcc to use OMF". Can be hard-wired in .mk files
and/or environmental variables and/or a passed parameter and/or "new
compiler"
-------------------------------

Your comment of "-Zomf inside HB_USER_CFLAGS" belong to my explanation
Yes, this choice are hidden to user, as hard-wired in .mk files and
other choices are too.
I do not like anything which is hidden to user or which force to user to
edit/change some Harbour file

For that reason I selected "environmental variable" as choice because
are exposed to user and have same behaviour / purpose than rest of our
environmental variables: values set by user to inform Harbour to do
something which we want

In this case HB_OS2_OMF or some like it, as "unavoidable switch", inform
to Harbour to inform gcc the use of his "unavoidable -Zomf switch"

You found and now have clear this need/behaviour when you made your
changes for replace my commit (with HB_OS2_OMF) with your commit (with
HB_COMPILER)

Do not waste time trying to implement autodetection, here does not apply
And maybe you should revert your "gccomf" implementation later

As you understand clearly all these discussions exist and are due you
reject my "new dimension" proposal even it is perfectly controlled,
which is an unavoidable switch in Harbour for an unavoidable switch in
os2gcc

Consequences of capability to manage two choices  :-)
If you want one at a time, you need an unavoidable declaration

os2gcc manage two choices and declarate one with -Zomf, Harbour manage
two choices and declarate one with HB_OS2_OMF or something like it

os2gcc will mantain a.out as default and will not drop -Zomf

Harbour can mantain a.out as default or set OMF as default, but at last
need the "unavoidable" switch, either my HB_OS2_OMF=yes|other or your
HB_COMPILER=gccomf|gcc

If we use only OMF in Harbour we do not need any choice and you have to
revert/remove the wires of your gccomf

Since beginning this option was considered: select one type, and you
requested it some times
As you have seen, I allways defend the two-choices option with
unavoidable switch, mainly by:
- os2gcc have that capacity and Harbour can have it too
- Maurilio expressed preference for a.out without having tested OMF

I explained many times: I made work to mantain a.out as default and use
optionally OMF without affect anything
People can be working with a.out as ever without need to know about OMF
choice with optional HB_OS2_OMF

But now Maurilio are closer to test OMF because work for it are not in
my machine but publicly in SVN

If he find OMF maturity and well behaviour in Harbour then we can think
to set as only option in Harbour for OS/2
And now he can use gcc4xx immediatly too

I suggest:
- Keep for a time current implementation with gccomf until we confirm
maturity and resolve any pending problems
Yes, I know, harbourm.dll overflow  :-)
- Forget to waste time for autodetection meanwhile
- Then we can drop safely a.out and disassemble work for two choices

But, a GREAT BUT, I prefer to leave two choices as "undocumented
feature" available with HB_OS2_AOUT (now a.out is not default) and not
HB_COMPILER=gccomf
Yes, I know you do not like "undocumented feature" but they are useful
and Harbour have many of them
And yes, you want HB_COMPILER structure but involve more maintenance
than HB_OS2_AOUT. In future somebody will ask: which is gccomf (or
gccaout or gcccoff ) compiler ?

Remember two things:
- Is much easy to remove than construct. Both implementations do the
same work, just choose one with minimal requirements
- For me to add OMF support to gcc.mk was easy, but to add to hbmk2.prg
was hard (browse in more than 7,000 lines to find where to put
something) so I applied in extremaly short section and only where it is
required
In your implementation you must take care of gccomf across all hbmk2.prg
Obviously the best is an combination of my controlled application and
your style using your well-known hbmk2.prg structures like
  AAdd( hbmk[ _HBMK_aOPTC ], "-Zomf" )
That was planned for third stage


Notes about OpenWatcom for OS/2
- I started to test OpenWatcom for OS/2 a year ago
- At start it does not work with Harbour, then Przemek gave me
guidelines and he corrected anything necessary to put to work
- Then you, Przemek and other mantained OpenWatcom as a good option for
Harbour including OS/2
- At that time I commented my nice surprise with OpenWatcom for OS/2:
a great compiler, complete, well done, fast, easy to setup,
well-documented, many tools, cross-platform and so on
- OpenWatcom use OS/2-OMF natively
- OpenWatcom build entirely Harbour in 8 minutes
gcc335-a.out does in 25 and gcc335-OMF does in 32 minutes

OpenWatcom for OS/2 have many clear advantages over os2gcc
If forced to choose a compiler for Harbour-OS/2 I immediatly will select
OpenWatcom. This also leave behind many problems with os2gcc

I do not choice mainly:
- I want to mantain support for available compilers used in Harbour-OS/2
- Main universe of OS/2 developers are in os2gcc


I am sure forget two or three things on the way, I hope it does not
raise or recall doubts  :-)
If so, just let me know

David Macias




_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to