[WIP] Legacy Makefiles

[Neui]

Includes an makefile generator that should be able to generate non-independent makefiles with certain settings (system, compiler). Builds upon PR #184 (so that should be merged first), originally from PR #164. Still Work In Progress.

Unlike the makefiles in the historical folder, this creates one big makefile that contains everything you need to build. It also uses the substitution feature heavily to cut down the size by not listing each file and how to commpile.

At the moment it generates the following makefiles:

• posix (should be compatible with basic POSIX systems, including linux/gcc)
• gcc (like POSIX but with gcc stuff)
• mingw (like GCC but for windows, currently untested)
• dos_gcc (like gcc/mingw but uses a dos-specific option -m486, untested)
• win32cl (for Microsofts CL compiler, usually included with Visual Studio, untested)
• amiga (uses SAS/C and smake, untested)
• amiga_gcc (uses gcc but also uses amiga system tools, untested)

Note that most are actually untested. Also it only builds, it doesn't do any testing or similar, since that would currently overcomplicate things.

I've also noticed that you can't really built inside of (Free)DOS because of the 8.3 name limitation with undistinguishable names (like decode_6502.c and decode_65816.c would both be truncated to decode_6.c). DOSBOX seems to use (Windows-Style?) short names, so that might work, but untested because of OpenWatcom.

This PR currently includes OpenWatcom as a compiler, BUT their C compiler for include files first searches the current working directory instead of the directory of the file currently being compiled, unlike other C compilers like GCC or CLang. (I am not sure if SAS/C (amiga) also has different behaviour.) Because of this, I probably gonna put it into a separate branch and maybe work on it on a later date (or maybe never). In other words, this PR won't have OpenWatcom support at the time of the merge.

A question I have is should we put the generated files also in the repo or offer an separate source package with such files pre-generated? I would prefer the last one since the git repository shouldn't contain any generated files (since they can be generated and thus be "outdated").

(Note that GitHub displays commits in date order. I heavily rebased this and since I didn't fixed the dates, this appears nonsensical. You might want to view this in a client that orders the commits on how it is actually stored, like most git clients).

[cr1901]

I've also noticed that you can't really built inside of (Free)DOS because of the 8.3 name limitation with undistinguishable names (like decode_6502.c and decode_65816.c would both be truncated to decode_6.c).

Some DOSes have LFN support via a driver, and Idk whether Ville ever actually built WLA on DOS (@vhelin could you chime in :D?). I just know that DOS machines w/ 386 CPU and above had binaries for WLA for a while.

Main reason to keep DOS support around IMO is that there are decent tools for retro dev which only still exist on retro systems, so might as well keep the assembler around as well :P.

In other words, this PR won't have OpenWatcom support at the time of the merge.

Fortunately, the legacy Makefiles never had this either :) (at least I don't think they did- if they did, it was because I added it, and I never meaningfully used that support before CMake.)

[vhelin]

On Sun, Feb 17, 2019 at 7:11 PM William D. Jones ***@***.***> wrote: I've also noticed that you can't really built inside of (Free)DOS because of the 8.3 name limitation with undistinguishable names (like decode_6502.c and decode_65816.c would both be truncated to decode_6.c). Some DOSes have LFN support via a driver, and Idk whether Ville ever actually built WLA on DOS ***@***.*** <https://github.com/vhelin> could you chime in :D?). I just know that DOS machines w/ 386 CPU and above had binaries for WLA for a while.

Uh, I don't really remember how the DOS makefiles were born. If I wrote them, then they were done in Win95/Win98 CMD shell as I've never had a PC home with just DOS, only Linux or Windows 95/98/XP/7/8/10.

Main reason to keep DOS support around IMO is that there are decent tools for retro dev which only still exist on retro systems, so might as well keep the assembler around as well :P.

Yeah! If we can have a working (pure) DOS support, that would be nice. PS. If the generated Makefile(s) are in a separate source package, not in the Git repo, where would they be? And how to make sure they are in sync with the Git repo? PPS. Is this going to replace CMake? PPPS. That's a massive amount of work you've done here! :) —

…

You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#216 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGHtUjjMwgcAhVsCWcJTXRQ0UFL5hdTVks5vOY0qgaJpZM4a_pt3> .

[Neui]

Yeah! If we can have a working (pure) DOS support, that would be nice.

Note that I haven't tested compiling ON (Free)DOS yet. It also uses an option called -m486, which probably means it would compile for i486, where DOS also supports i386, so it might not work for the full range of hardware.

Also there are of course cross compilers like DJGPP-GCC, that might work with the CMake build system generator. I haven't tried it yet.

PS. If the generated Makefile(s) are in a separate source package, not in the Git repo, where would they be? And how to make sure they are in sync with the Git repo?

I mean when a release is being done (doing an annotated tag), then you can upload additional files to that tag(/Release in GitHub) and you could then upload the source code but with those generated files included (which are located in mk which then the user picks out).

PPS. Is this going to replace CMake?

No, they co-exist. CMake can generate files for IDEs (like Visual Studio) and other build systems (Ninja), and better integration with other tools (compilation database, there's also an daemon version).

PPPS. That's a massive amount of work you've done here! :)

Thanks! I actually had this for a while, with good weather now I added amiga support and refined it a little.

(Note that I noticed some mistakes and fixed them, but it still needs testing)

[cr1901]

I would like to test on Amiga, but I don't have the hardware (perhaps I could set an emulator up if someone can provide me w/ the relevant C compiler, or @Neui can do it and just see if the tests run :)?).

AIUI, one killer app for Amiga for retro dev is their version of Deluxe Paint, which Idk if it has a good equivalent even today!

For VB dev, I can get Paint dot net to generate output files in the appropriate format, but it isn't exactly wieldy (requires python scripts).

[Neui]

Note that the "testing" here is just checking whenever it builds and the binaries run.

I can check mingw and win32cl by myself, it's just I haven't done it yet. With dos_gcc I've looked up that there's an LFN program/driver for FreeDOS that I might try (together with DJGPP-GCC). Since I never had a amiga and it seems that (at least) the OS is not free, and I don't really want to give out money for something I then probably never use.

Note that my main procedure was to just look at the makefiles and try to recreate the commands.

[Neui]

Current state of the art:

Using DJGPP-GCC I am able to compile on FreeDOS (on a virtual machine) and it works. Note that it seems it compiles (and runs) programs in protected mode, not real mode, so it isn't completely DOS compatible (or at least pre 286/386 CPUs). Currently the main "problem" is that for cleanup, it complains that the command is too long. I just have to implement wildcard expression and it should be OK. In addition, I've renamed dos_gcc.mk to dosdjgpp.mk, because it was made and tested with DJGPP-GCC.

Microsofts CL compiler (win32cl.mk) also works. I've removed /Zw since VS2013 and VS2017 doesn't detect it. MinGW also works.

I also plan to polish the mk/README.md, mainly adding make variables you can change. Feedback appreciated.

There is still no testing about the makefiles for Amiga, since I don't have one. If nobody can test it, what about excluding them until we can? Since otherwise this PR (and the CMake one) would then just get stalled for no real added benefit if it doesn't work and most people probably gonna compile on modern systems anyway; It can always be added later.

Also it seems some old makefiles also strip the binaries and some don't. Should I also include stripping for all binaries? I'd say yes to get the size down.

[cr1901]

@vhelin When this is complete, perhaps one of us could look into getting CI running to make sure each target builds (and tests pass)?

Using shell scripts specifically for CI purposes should be reasonable. Just need to figure out how to reliably test Amiga target via emulation (DOSBOX already has a mechanism to run a single binary and return stdin/stdout to the OS).

[Neui]

In the old PR I actually had some CI support for some services, but not really for this legacy makefiles. I'll have to look up about DOSBOX. Also, since you can/need to buy the amiga OS, emulation becomes hard because the build scripts are globally readable and if they contain how to get that OS for free, it might be bad for us.

[vhelin]

On Mon, Feb 18, 2019 at 2:40 AM William D. Jones ***@***.***> wrote: I would like to test on Amiga, but I don't have the hardware (perhaps I could set an emulator up if someone can provide me w/ the relevant C compiler, or @Neui <https://github.com/Neui> can do it and just see if the tests run :)?).

WinUAE + SAS/C 6.58 should do the trick, I think. Here you can find the SAS/C C-compiler: http://eab.abime.net/showthread.php?t=62857&highlight=sasc658.lha

…

AIUI, one killer app for Amiga for retro dev is their version of Deluxe Paint, which Idk if it has a good equivalent even today! For VB dev, I can get Paint dot net to generate output files in the appropriate format, but it isn't exactly wieldy (requires python scripts). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#216 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGHtUh7A9sH5RIRL5ApTYrz6qr2zbca1ks5vOfZjgaJpZM4a_pt3> .

[vhelin]

On Wed, Feb 20, 2019 at 4:58 PM Neui ***@***.***> wrote: Current state of the art: Using DJGPP-GCC I am able to compile on FreeDOS (on a virtual machine) and it works. Note that it seems it compiles (and runs) programs in protected mode <http://www.delorie.com/djgpp/doc/ug/basics/protected.html>, not real mode, so it isn't completely DOS compatible (or at least pre 286/386 CPUs). Currently the main "problem" is that for cleanup, it complains that the command is too long. I just have to implement wildcard expression and it should be OK. In addition, I've renamed dos_gcc.mk to dosdjgpp.mk, because it was made and tested with DJGPP-GCC.

For me running in protected mode is good enough. :)

Microsofts CL compiler (win32cl.mk) also works. I've removed /Zw since VS2013 and VS2017 doesn't detect it. MinGW also works. I also plan to polish the mk/README.md <https://github.com/Neui/wla-dx/blob/legacy-mkfiles/mk/README.md>, mainly adding make variables you can change. Feedback appreciated. There is still no testing about the makefiles for Amiga, since I don't have one. If nobody can test it, what about excluding them until we can? Since otherwise this PR (and the CMake one) would then just get stalled for no real added benefit if it doesn't work and most people probably gonna compile on modern systems anyway; It can always be added later.

If no-one else has the time or energy or resources to test the makefiles for Amiga, I think I could setup WinUAE with SAS/C C-compiler... You could also submit a pull request with non tested Amiga support and we'd just test it later. I'm sure it wouldn't cause any trouble among Amiga users are there might not be many of them around. :)

Also it seems some old makefiles also strip the binaries and some don't. Should I also include stripping for all binaries? I'd say yes to get the size down.

I guess all non-debug executables could be stripped without any problems?

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#216 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGHtUuBn3YpBLTDbO1yweKYPT3DVKpmsks5vPWKHgaJpZM4a_pt3> .

[vhelin]

On Thu, Feb 21, 2019 at 4:30 AM William D. Jones ***@***.***> wrote: @vhelin <https://github.com/vhelin> When this is complete, perhaps one of us could look into getting CI running to make sure each target builds (and tests pass)?

I have to admit that I don't know completely what I would need to do. :)

…

Using shell scripts specifically for CI purposes should be reasonable. Just need to figure out how to reliably test Amiga target via emulation (DOSBOX already has a mechanism to run a single binary and return stdin/stdout to the OS). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#216 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGHtUjq2UQFjYyIyWpugRZ_qzDAT3DNUks5vPgS-gaJpZM4a_pt3> .

[cr1901]

I have to admit that I don't know completely what I would need to do. :)

I have experience w/ Travis, I could look into it.

If no-one else has the time or energy or resources to test the makefiles for Amiga, I think I could setup WinUAE with SAS/C C-compiler...

That would be wonderful :). How would you get around the copyright problem for the ROMs that @Neui mentioned? There seems to be an alternative OS called AROS that can run Amiga 3.x binaries.

Amiga 4.x can run GCC; dunno offhand how to build a libc for that, but even ancient versions of GCC (like 2.x) shouldn't choke on wla-dx.

[vhelin]

On Thu, Feb 21, 2019 at 8:03 PM William D. Jones ***@***.***> wrote: I have to admit that I don't know completely what I would need to do. :) I have experience w/ Travis, I could look into it.

Cool! If no-one else has the time or energy or resources to test the makefiles

for Amiga, I think I could setup WinUAE with SAS/C C-compiler... That would be wonderful :). How would you get around the copyright problem for the ROMs that @Neui <https://github.com/Neui> mentioned? There seems to be an alternative OS called AROS that can run Amiga 3.x binaries. Amiga 4.x can run GCC; dunno offhand how to build a libc for that, but even ancient versions of GCC (like 2.x) shouldn't choke on wla-dx.

Actually, one of my friends has a working Amiga 1200. Perhaps he could give us a hand here? I'll ask! —

…

You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#216 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGHtUrd3wru86GYek9c-W2SN65r18Qkwks5vPt9pgaJpZM4a_pt3> .

[vhelin]

About Amiga support, I contacted my friend and together we fixed the historical makefiles to work once again. If you want to build WLA DX on an Amiga, you'll have to use SAS/C, or write your own makefiles... For those who want to see what SAS/C 6.58 outputs when run on an Amiga, here's the data (just compiling wla-gb): ... SAS/C_SMAKE 6.58 (27.12.96) Copyright (c) 1988-1995 SAS Institute, Inc. sc define AMIGA=1 define GB=1 main.c Using options file "scoptions" Compiler Phase 1 for "main.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "main.c" Compiler Phase 2 for "main.c" Module size P=000010C2 D=00000068 U=00000AC2 sc define AMIGA=1 define GB=1 parse.c Using options file "scoptions" Compiler Phase 1 for "parse.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "parse.c" parse.c 314 Warning 304: dead assignment eliminated "e" parse.c 972 Warning 304: dead assignment eliminated "ret" Compiler Phase 2 for "parse.c" Module size P=000019F2 D=00000014 U=00000510 sc define AMIGA=1 define GB=1 include_file.c Using options file "scoptions" Compiler Phase 1 for "include_file.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "include_file.c" Compiler Phase 2 for "include_file.c" Module size P=000013D6 D=00000068 U=0000000C sc define AMIGA=1 define GB=1 pass_1.c Using options file "scoptions" Compiler Phase 1 for "pass_1.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "pass_1.c" pass_1.c 2584 Warning 304: dead assignment eliminated "sj" pass_1.c 2897 Warning 317: possibly uninitialized variable "m" pass_1.c 2901 Warning 317: possibly uninitialized variable "m" pass_1.c 5570 Warning 304: dead assignment eliminated "rr" Compiler Phase 2 for "pass_1.c" Module size P=00011C54 D=00000908 U=00003372 C=00000000 F=00002030 UF=00000000 sc define AMIGA=1 define GB=1 pass_2.c Using options file "scoptions" Compiler Phase 1 for "pass_2.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "pass_2.c" Compiler Phase 2 for "pass_2.c" Module size P=00000642 D=00000044 U=00000000 sc define AMIGA=1 define GB=1 pass_3.c Using options file "scoptions" Compiler Phase 1 for "pass_3.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "pass_3.c" Compiler Phase 2 for "pass_3.c" Module size P=0000146E D=0000000C U=0000000C sc define AMIGA=1 define GB=1 pass_4.c MATH=STANDARD Using options file "scoptions" Compiler Phase 1 for "pass_4.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "pass_4.c" Compiler Phase 2 for "pass_4.c" Module size P=00003D2E D=00000018 U=0000074E sc define AMIGA=1 define GB=1 stack.c Using options file "scoptions" Compiler Phase 1 for "stack.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "stack.c" stack.c 541 Warning 317: possibly uninitialized variable "si" stack.c 542 Warning 317: possibly uninitialized variable "si" stack.c 544 Warning 317: possibly uninitialized variable "si" stack.c 545 Warning 317: possibly uninitialized variable "si" stack.c 590 Warning 317: possibly uninitialized variable "si" stack.c 591 Warning 317: possibly uninitialized variable "si" Compiler Phase 2 for "stack.c" Module size P=0000233C D=00000024 U=00000000 sc define AMIGA=1 define GB=1 listfile.c Using options file "scoptions" Compiler Phase 1 for "listfile.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "listfile.c" Compiler Phase 2 for "listfile.c" Module size P=00000638 D=00000000 U=00000000 sc define AMIGA=1 define GB=1 crc32.c Using options file "scoptions" Compiler Phase 1 for "crc32.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "crc32.c" Compiler Phase 2 for "crc32.c" Module size P=0000004C D=00000400 U=00000000 sc define AMIGA=1 define GB=1 hashmap.c Using options file "scoptions" Compiler Phase 1 for "hashmap.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "hashmap.c" Compiler Phase 2 for "hashmap.c" Module size P=000004E8 D=00000000 U=00000000 slink STRIPDEBUG NOICONS FROM LIB:c.o main.o parse.o include_file.o pass_1.o pass_2.o pass_3.o pass_4.o stack.o listfile.o crc32.o hashmap.o TO wla LIB LIB:scm.lib LIB:sc.lib LIB:amiga.lib Slink - Version 6.58 Copyright (c) 1988-1995 SAS Institute, Inc. All Rights Reserved. SLINK Complete - Maximum code size = 180712 ($0002c1e8) bytes Final output file size = 171096 ($00029c58) bytes ... I'll try to fix the remaining warnings (I've already fixed some), and I'll try running the assembler and linker tomorrow.

…

On Thu, Feb 21, 2019 at 8:40 PM Ville Helin ***@***.***> wrote: On Thu, Feb 21, 2019 at 8:03 PM William D. Jones ***@***.***> wrote: > I have to admit that I don't know completely what I would need to do. :) > > I have experience w/ Travis, I could look into it. > Cool! If no-one else has the time or energy or resources to test the makefiles > for Amiga, I think I could setup WinUAE with SAS/C C-compiler... > > That would be wonderful :). How would you get around the copyright > problem for the ROMs that @Neui <https://github.com/Neui> mentioned? > There seems to be an alternative OS called AROS that can run Amiga 3.x > binaries. > > Amiga 4.x can run GCC; dunno offhand how to build a libc for that, but > even ancient versions of GCC (like 2.x) shouldn't choke on wla-dx. > Actually, one of my friends has a working Amiga 1200. Perhaps he could give us a hand here? I'll ask! — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#216 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AGHtUrd3wru86GYek9c-W2SN65r18Qkwks5vPt9pgaJpZM4a_pt3> > . >

[vhelin]

FYI, it gives me a warm feeling when I can compile WLA DX once again on Amiga using a 22 years old C compiler without any errors. :) Or is that the 9.45% belgian beer I just drank 1.5 liters while waiting for WLA DX to compile? :D

…

On Sat, Feb 23, 2019 at 12:01 AM Ville Helin ***@***.***> wrote: About Amiga support, I contacted my friend and together we fixed the historical makefiles to work once again. If you want to build WLA DX on an Amiga, you'll have to use SAS/C, or write your own makefiles... For those who want to see what SAS/C 6.58 outputs when run on an Amiga, here's the data (just compiling wla-gb): ... SAS/C_SMAKE 6.58 (27.12.96) Copyright (c) 1988-1995 SAS Institute, Inc. sc define AMIGA=1 define GB=1 main.c Using options file "scoptions" Compiler Phase 1 for "main.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "main.c" Compiler Phase 2 for "main.c" Module size P=000010C2 D=00000068 U=00000AC2 sc define AMIGA=1 define GB=1 parse.c Using options file "scoptions" Compiler Phase 1 for "parse.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "parse.c" parse.c 314 Warning 304: dead assignment eliminated "e" parse.c 972 Warning 304: dead assignment eliminated "ret" Compiler Phase 2 for "parse.c" Module size P=000019F2 D=00000014 U=00000510 sc define AMIGA=1 define GB=1 include_file.c Using options file "scoptions" Compiler Phase 1 for "include_file.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "include_file.c" Compiler Phase 2 for "include_file.c" Module size P=000013D6 D=00000068 U=0000000C sc define AMIGA=1 define GB=1 pass_1.c Using options file "scoptions" Compiler Phase 1 for "pass_1.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "pass_1.c" pass_1.c 2584 Warning 304: dead assignment eliminated "sj" pass_1.c 2897 Warning 317: possibly uninitialized variable "m" pass_1.c 2901 Warning 317: possibly uninitialized variable "m" pass_1.c 5570 Warning 304: dead assignment eliminated "rr" Compiler Phase 2 for "pass_1.c" Module size P=00011C54 D=00000908 U=00003372 C=00000000 F=00002030 UF=00000000 sc define AMIGA=1 define GB=1 pass_2.c Using options file "scoptions" Compiler Phase 1 for "pass_2.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "pass_2.c" Compiler Phase 2 for "pass_2.c" Module size P=00000642 D=00000044 U=00000000 sc define AMIGA=1 define GB=1 pass_3.c Using options file "scoptions" Compiler Phase 1 for "pass_3.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "pass_3.c" Compiler Phase 2 for "pass_3.c" Module size P=0000146E D=0000000C U=0000000C sc define AMIGA=1 define GB=1 pass_4.c MATH=STANDARD Using options file "scoptions" Compiler Phase 1 for "pass_4.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "pass_4.c" Compiler Phase 2 for "pass_4.c" Module size P=00003D2E D=00000018 U=0000074E sc define AMIGA=1 define GB=1 stack.c Using options file "scoptions" Compiler Phase 1 for "stack.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "stack.c" stack.c 541 Warning 317: possibly uninitialized variable "si" stack.c 542 Warning 317: possibly uninitialized variable "si" stack.c 544 Warning 317: possibly uninitialized variable "si" stack.c 545 Warning 317: possibly uninitialized variable "si" stack.c 590 Warning 317: possibly uninitialized variable "si" stack.c 591 Warning 317: possibly uninitialized variable "si" Compiler Phase 2 for "stack.c" Module size P=0000233C D=00000024 U=00000000 sc define AMIGA=1 define GB=1 listfile.c Using options file "scoptions" Compiler Phase 1 for "listfile.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "listfile.c" Compiler Phase 2 for "listfile.c" Module size P=00000638 D=00000000 U=00000000 sc define AMIGA=1 define GB=1 crc32.c Using options file "scoptions" Compiler Phase 1 for "crc32.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "crc32.c" Compiler Phase 2 for "crc32.c" Module size P=0000004C D=00000400 U=00000000 sc define AMIGA=1 define GB=1 hashmap.c Using options file "scoptions" Compiler Phase 1 for "hashmap.c" No errors; No warnings; No user suppressed warnings Global Optimizer for "hashmap.c" Compiler Phase 2 for "hashmap.c" Module size P=000004E8 D=00000000 U=00000000 slink STRIPDEBUG NOICONS FROM LIB:c.o main.o parse.o include_file.o pass_1.o pass_2.o pass_3.o pass_4.o stack.o listfile.o crc32.o hashmap.o TO wla LIB LIB:scm.lib LIB:sc.lib LIB:amiga.lib Slink - Version 6.58 Copyright (c) 1988-1995 SAS Institute, Inc. All Rights Reserved. SLINK Complete - Maximum code size = 180712 ($0002c1e8) bytes Final output file size = 171096 ($00029c58) bytes ... I'll try to fix the remaining warnings (I've already fixed some), and I'll try running the assembler and linker tomorrow. On Thu, Feb 21, 2019 at 8:40 PM Ville Helin ***@***.***> wrote: > > > On Thu, Feb 21, 2019 at 8:03 PM William D. Jones < > ***@***.***> wrote: > >> I have to admit that I don't know completely what I would need to do. :) >> >> I have experience w/ Travis, I could look into it. >> > > Cool! > > If no-one else has the time or energy or resources to test the makefiles >> for Amiga, I think I could setup WinUAE with SAS/C C-compiler... >> >> That would be wonderful :). How would you get around the copyright >> problem for the ROMs that @Neui <https://github.com/Neui> mentioned? >> There seems to be an alternative OS called AROS that can run Amiga 3.x >> binaries. >> >> Amiga 4.x can run GCC; dunno offhand how to build a libc for that, but >> even ancient versions of GCC (like 2.x) shouldn't choke on wla-dx. >> > > Actually, one of my friends has a working Amiga 1200. Perhaps he could > give us a hand here? I'll ask! > > — >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub >> <#216 (comment)>, or mute >> the thread >> <https://github.com/notifications/unsubscribe-auth/AGHtUrd3wru86GYek9c-W2SN65r18Qkwks5vPt9pgaJpZM4a_pt3> >> . >> >

[cr1901]

It's really exciting for me too. I'm glad you were receptive to keeping the source c89 compatible. I'm glad its paying off now :3.

If ppl get worried about buffer overflows later (and I agree that some c89 functions are dangerous), we can provide our own copies of snprintf and friends.

Did your friend give any ideas about how to add Amiga building to CI using emulation (without copyright problems)?

[Neui]

I've implemented RM glob, so deleting on DOS should work. Also, DOSBOX doesn't work since while it converts long filenames to short ones, it actually doesn't support the LFN API, so it actually fails (to find include_file.h). Also it seems you can't really output the console to stdout, and it needs an X display (runs via SDL). While there's an LFN patch for DOSBOX, they just provide "changed" files without an revision on what it is based on. Maybe I'll look into it, but not now.

I didn't implemented stripping because I didn't wanted to create a another variable just for it. I'd say just modify LDFLAGS if you like to strip (or run the strip binary).

I've also noticed the amiga fixes. However I've a few questions: Did you test with this PR? Does the include files depend on where the source file is, or where the call to the compiler is emitted or ..? Does it support relative file paths? Is the / the root directory of an drive or the source folder?

[Neui]

I've rebased it and pushed it;

git merge --abort
git fetch origin pull/216/head
git checkout FETCH_HEAD

or

git merge --abort
git remote add neui https://github.com/Neui/wla-dx
git fetch neui
git checkout neui/legacy-mkfiles

[vhelin]

This is what I get...

[Neui]

It looks like SMake doesn't support substituting variables, which is a major pain. It also explains why every SMakefile explicitly lists all files and their object files rather than substituting. Maybe I'll do an separate script that is specifically tailored to SMake/SAS.

[cr1901]

It looks like SMake doesn't support substituting variables, which is a major pain. It also explains why every SMakefile explicitly lists all files and their object files rather than substituting. Maybe I'll do an separate script that is specifically tailored to SMake/SAS.

This is probably for the best, unfortunately. There is in practice no such thing as a portable Makefile.