>> Przemek, Viktor, Maurilio:
>>
>> As make381-os2 show problems (limits) and incompatibility with
>> make381-windows (and perhaps Linux), there are some way to use
>> ANOTHER make system in OS/2 ?
>> Reading docs of Watcom I found wmake.exe, based in GNU make but with
>> some differences specified in docs
>> I tried to use it to build Harbour and raised errors not described
>> in differences
>No, sorry. I'd certainly not want to reintroduce a parallel (non-GNU)
>make system for OS/2 after having spent a year getting rid of them
>for Windows (and all the permanent double work with them).
>Probably it would be better to find a GNU Make build for OS/2 which
>works well, or trying to work around the bugs which it has under
>OS/2. I don't exactly see what are these though, can't find any lines
>like "for %i in ( *.obj ) do @echo -+%i >> __lib__.tmp" in current SVN.
>[ It'd recommend to make tests using latest SVN, as changes are made
>regularly in the GNU Make process. Also, confirmed pending patches
>should better be uploaded to SVN, as currently it's very difficult to
>track what is the tested codebase. The only slight problem I see with
>these watcom patches, is that it's not too clean and for cross-
>compilation
>it would have to be added to all watcom.cf files, just to make OS/2
>happy. ]
>It should also be noted that our GNU Make process uses shell specific
>rules and parts, and some other OS specific tricks so maybe not GNU
>Make itself should be blamed for some problems you're seeing.
>It may also be an option to use the DOS build of GNU Make under OS/2.
>I don't know to what extent OS/2 is compatible with DOS exes, but it's
>worth a check.
Viktor:
The short history is:
I have years building Harbour under OS/2 using os2make376. In February
2008 Przemek added changes to "make process" not supported by
os2make376. I checked some versions of os2make381 and all of them show
problems. Przemek reversed his changes.
Until December 2008 os2make376 was able to build Harbour using gcc335
and Watcom 1.7a
This year you changed make process and in meantime some workarounds for
OS/2-os2make376 were left off. Now Harbour under OS/2 does not build
with os2make376 and partially build with os2make381
We are currently discarding os2make376 and forcing to use os2make381,
and trying to find why and how to apply workarounds
Line "for %i in ( *.obj ) do @echo -+%i >> __lib__.tmp" are not in SVN
because is part of "local tests" to find solutions
I have reported many of these issues in my previous messages and Przemek
has explained many of the reasons also.
"install" and "clean" stages show a lot of errors. At this moment we are
trying to get a complete build of Harbour with workarounds and without
problems. Then we can concentrate in "install" and "clean"
Przemek has been working deeply to find right workarounds. He knows much
better than me what are the problems and how to clean them
My tests in real OS/2 environment show the results and I contribute to
clarify problems and propose alternatives
There were the cases with gcc335 build, OpenWatcom 1.8 build, os2->win
cross build and win->os2 cross build. Each of them show different
problems with os2make381
And additionally, differences between os2make381 and winmake381
Przemek explained some days ago:
>Yes and it's a bug in OS2 GNU make port we are exploiting from time to
>time.
>If we find some acceptable solution the we will use it. If not we will
>have to return to the:
> for %i in ( *$(OBJ_EXT) ) do @echo ... >> __lib__.tmp
>trick and add some hack to protect against adding hbpp.obj to library.
I do not know if Maurilio has done test with OpenWatcom 1.8, native and
cross build. If so then he can see problems, some of them faced with gcc
version
My proposal was simple:
If os2make381 have problems, and wmake.exe (OpenWatcom) with some
adjustments can do same process as os2make381, then we can discard
os2make381 and to use wmake.exe
As you can see is not to introduce a parallel make process. Is to use
same structure of current GNUmake with proper adjustments
Below are some parts of Watcom Tools Guide related to wmake
David Macias
---------------
Some readers will be quite familiar with the concepts of the Make file
maintenance tool. Open Watcom Make is patterned after the Make utility
found on UNIX systems. The next major section is simply intended to
summarize, for reference purposes only, the syntax and options of Make's
command line and special macros. Subsequent sections go into the
philosophy and capabilities of Open Watcom Make. If you are not familiar
with the capabilities of the Make utility, we recommend that you skip to
the next major section entitled "Dependency Declarations" and read on.
---------------
Open Watcom Make was originally based on the UNIX Make utility. The PC's
operating environment presents a base of users which may or may not be
familiar with the UNIX operating system. Make is designed to be a PC
product with some UNIX compatibility. The line continuation in UNIX Make
is a backslash ("\") at the end of the line. The backslash ("\") is used
by the operating system for directory specifications and as such will be
confused with line continuation. For example, you could type:
cd \
along with other commands ... and get unexpected results. However, if
your makefile does not contain path separator characters ("\") and you
wish to use "\" as a line continuation indicator then you can use the
Make "u" (UNIX compatibility mode) option.
Also, in the UNIX operating system there is no concept of file
extensions, only the concept of a file suffix. Make will accept the UNIX
Make directive .SUFFIXES for compatibility with UNIX makefiles. The UNIX
compatible special macros supported are:
Macro
Expansion
$@
full name of the target
$*
target with the extension removed
$<
list of all dependents
$?
list of dependents that are younger than the target
The extra checking of makefiles done by Make will require modifications
to UNIX makefiles. The UNIX Make utility does not check for the
existence of targets after the associated command list is executed so
the "c" or the .NOCHECK directive should be used to disable this
checking. The lack of a command list to update a target is ignored by
the UNIX Make utility but Open Watcom Make requires the special internal
command %null to specify a null command list. In summary, Make supports
many of the features of the UNIX Make utility but is not 100% compatible.
---------------
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
