Viktor:
>I don't plan to do it. The reason is two-fold, first it makes
>the layout messy, second this solution can only solve the problem
>temporarily. Sooner or later we will have additional objects which
>are part of .dlls, and in this case it will just break again,
>for both .dlls.
>So I suggest to solve the root cause instead of adding such
>workaround.
I do not see two-fold as layout messy
In Harbour we have added, deleted, moved directories oftenly
And for additional objects, yes, I saw it as a future problem
Two-fold was my temporary solution to build entirely Harbour in either
library format and is suggested as an optional way
Current failure to build harbourm.dll must not stop us in other goals
>> If someone want to build Harbour with gcc335/OMF type or gcc4xx/OMF
>> type, just need to set:
>>
>> set EMXOMFLD_TYPE=WLINK ( or prefered choice )
>> set EMXOMFLD_LINKER=WL.EXE ( or prefered choice )
>> set HB_OS2_OMF=yes
>>
>> With current diff output and moving "source\dynlib\mt" all work is
>> done
>Thanks for the patch, but sorry, I still don't support this
>method for reasons described multiple times. It's an
>out-of-the-band bunch of options, so for me it's still in
>the hack area. I also don't understand why to introduce
>additional EMXOMDLD_* variables. I'm trying to REDUCE
>number of control variables and to keep the main logic as
>straightforward, simple and portable as possible, this
>patch goes to the other direction.
This goes in the same direction: simple and portable as possible
It was explained since beginning
os2gcc is not linuxgcc, darwingcc, sunosgcc, ... and any other gcc, so
os2gcc have/support other features and have specific needs
The only work we have to do is to manage these features in Harbour
set EMXOMFLD_TYPE=WLINK ( or prefered choice )
set EMXOMFLD_LINKER=WL.EXE ( or prefered choice )
together with -Zomf are used by gcc itself to manage library format as
OMF in place of a.out
Both values are not used by Harbour and belong to C compiler setting
You can exclude any reference of these values in INSTALL and/or Harbour
but end-users may ignore them failing as consequence
set HB_OS2_OMF=yes
is the only new value for Harbour, and we need it or something as it
because in some place we need to tell to Harbour "make process" that we
are using a different type, and in some pieces of Harbour code
In fact, HB_OS2_OMF is not used in Harbour code in any place except
hbmk2.prg, because we need to inform hbmk2.prg that os2gcc manage two
choices
Same is need for any other compiler where we change default values, as
library format in this case
A value as "set HB_OS2_OMF=yes" was my "simple as possible" proposal for
this need of os2gcc
Perhaps we can discard this new ONE specific OS/2 value and manage the
two options of library format on os2gcc based ih other value, for
example "not empty EMXOMFLD_TYPE" environment value
As in case of HB_OS2_OMF, "not empty EMXOMFLD_TYPE" must be used in
config\os2\gcc.mk
utils\hbmk2\hbmk2.prg
implying it mean "OMF type" in place of "a.out type"
In this way we do not need any new values in Harbour and any reference
in INSTALL of these two gcc values (we discarded HB_OS2_OMF) and
sucessful build of Harbour rely only on proper gcc environment settings
applied by end-user
I see this choice against of spirit of INSTALL, when we suppose it exist
to help Harbour builders
A new os2gcc value in Harbour (HB_OS_OMF) must not stop us in other
goals: support of OMF type and gcc4xx
The work has been done and is just matter to include it to Harbour,
expanding Harbour capabilities, keeping it simple
David Macias
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
