David,
with my latest changes I can build harbour on OS/2 using GCC and make (even
make -j n works).
Maurilio.
> >> 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
>
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
