Hi Andrew,
Sunday August 25 2013 16:01, you wrote to me:
ac> 24 Aug 13 23:18, you wrote to me:
US>> than it is in sync, as I've unpacked the tarball downloaded as
US>> http://makenl.cvs.sourceforge.net/viewvc/makenl/?view=tar
US>> and used it for compile in a plain version control system free
US>> directory the only difference was the make file that doesn't work
US>> with the long filename for the .watcom so I have to customize
US>> this makefile so it works under 8.3 filename convention, copied
US>> over the makefile
ac> Renaming it to makefile.wat should work.
from a long series of trial and errors to get watcom to compile under os/2 and
to use the correct libs and includes paths, I had a customized makefile
that I've copied over from revision to revision compile
so that I've extracted the tarball and copied over the customized make file. the
last time I've started the os/2 watcom compiler is about 4 weeks ?!?
old so I don't remind all the details, that I've used in this project
to get the compile running ... especialy with the debugging / non debugging ...
don't expected that the makefile did change ... copied over ...
compile ... fail .. problem identified ... the pat* thingee ...
while comparing both files on another machine, after your reply, I've found
that there is not much difference in the makefile except the pat*
but this does nothing have to do with rest of the files from the tarball.
I cannot get the files from the cvs you're pushing to sourceforge, I can only
download the tarball from sourceforge, and I have no idea, if the tarball
content is identical to the cvs raw content you're pushing to
as said .. download is possible for comparison by git, http, ftp .. so in this
section is the tarball is included ... but cvs isn't possible
is someone other able to compare the cvs content with the tarball
that is presented on the sourceforge website under makenl_ng ?!?
ac> I did not anticipate anyone still using FAT filesystem under OS/2 in
ac> 2013.
wrong assumption ...
lfn disabled on a mounted netdrive for longtime fallback compatibily reasons
in a mixed environment
ac> I have no more free time this week to look for the bug, so you'll
ac> have
ac> to investigate it yourself.
ac> The changes I made were fairly minimal, but it's possible patmat()
ac> isn't working as expected.
sounds that the tarball is identical to your cvs pushed directory
as the tarball includes the patmat.c/patmat.h and the modified makefile
so the reported problems processing segments stands :-P
as the compile didn't reported an error ...
ac> -$- GoldED+/BSD 1.1.5-b20110223-b20110223
ac> $ Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)
regards, uli ;-)
---
* Origin: AMBROSIA - Frankfurt/Main - Germany (2:244/1120)
|