Make tool

[andrewbird]

I did some experiments a few weeks ago in a test branch with Gnu Make. I find the make currently used on the project somewhat basic, particularly around escaping of the dollar sign. Anyway some good reductions in makefile duplication can be made, the necessity to build files like _x,sys then rename them in DOS to $x.sys can be removed and there are macros for text string manipulation etc. But this does come at a price:

• I see the build is noticeably slower (rough guess half speed)
• Since the copy of Gnu Make I have is built with DJGPP it means you need DPMI support on the build platform. So if you don't have that, you'd probably need to load cwsdmpi once after each boot.

For a good comparison of roughly 1/3 code
see the Gmake version
https://github.com/andrewbird/pcmos386/blob/build03/SOURCES/src/jim/term.gmk
and the NDmake version
https://github.com/andrewbird/pcmos386/blob/build03/SOURCES/src/jim/MAKETERM.MAK

What do people think about switching make, it doesn't necessarily have to be Gnu make, perhaps MS nmake or Borland's could be used instead?

Note: please ignore the fact the build is done in the 'jim' directory, and that it isn't rebased off the current master git version.

Edited: formatting

[the-grue]

I could get behind that. I also wouldn't mind eventually boiling everything down to one compiler and one assembler. It looks like @galazwoj put some effort into removing Borland C as a requirement. I don't see that any effort has been put into that fork since 2017 though.

The stuff that builds with Borland C may be easy to port or drop altogether as I am finding some of it is specific to v4 (install/hd_setup) and isn't really valid anymore. Effort put into converting it to another compiler and making the changes for v5 and onward might take longer than a rewrite.

For now, I am keeping my copies of Borland and MS documentation handy!

[galazwoj]

Please tell what task you consider the most important as I will be back on pcmos next month 😀 Czw., 7 lut 2019, 20:26: James T. Sprinkle <[email protected]> napisał(a):

…

I could get behind that. I also wouldn't mind eventually boiling everything down to one compiler and one assembler. It looks like @galazwoj <https://github.com/galazwoj> put some effort into removing Borland C as a requirement. I don't see that any effort has been put into that fork since 2017 though. The stuff that builds with Borland C may be easy to port or drop altogether as I am finding some of it is specific to v4 (install/hd_setup) and isn't really valid anymore. Effort put into converting it to another compiler and making the changes for v5 and onward might take longer than a rewrite. For now, I am keeping my copies of Borland and MS documentation handy! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#69 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZcXCI3O-bTRMLMbk4ztvQwVWfpwUOslks5vLH4CgaJpZM4an2Vi> .

[andrewbird]

@galazwoj it's good to hear that. I'm not sure about priorities myself, though I believe @the-grue fixed the 2012 date bug, so that's a major success.

@the-grue , you mention MS docs. Do you have documentation for the DOS version of their 'link', as personally I've been struggling with the command line argument object/library/mapfile placements? Searching with Google etc, is difficult as the results seem to be wholly for modern Windows versions.

[galazwoj]

link syntax https://www.pcjs.org/pubs/pc/reference/microsoft/mspl13/masm/mref/ You can also see .lnk files in pcmos source I created pt., 8 lut 2019 o 10:25 Andrew Bird <[email protected]> napisał(a):

…

@galazwoj <https://github.com/galazwoj> it's good to hear that. I'm not sure about priorities myself, though I believe @the-grue <https://github.com/the-grue> fixed the 2012 date bug, so that's a major success. @the-grue <https://github.com/the-grue> , you mention MS docs. Do you have documentation for the DOS version of their 'link', as personally I've been struggling with the command line argument object/library/mapfile placements? Searching with Google etc, is difficult as the results seem to be wholly for modern Windows versions. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#69 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZcXCB7Dl-cxY9I527q9i0E2KEfF0V9Bks5vLUKSgaJpZM4an2Vi> .

-- Wojciech Galazka

[andrewbird]

Oh yes I did use your .lnk files for reference, but I got a little confused regarding comma placement. I think just the single line from your link should help:

LINK objfiles [, [exefile] [, [mapfile] [, [libraries] [, [deffile] ] ] ] ][;]