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