vhelin / wla-dx

WLA DX - Yet Another GB-Z80/Z80/Z80N/6502/65C02/65CE02/65816/68000/6800/6801/6809/8008/8080/HUC6280/SPC-700/SuperFX Multi Platform Cross Assembler Package
Other
549 stars 98 forks source link

Compiling for MSYS2 or MinGW-w64? #186

Closed StarWolf3000 closed 5 years ago

StarWolf3000 commented 6 years ago

I'm using MSYS2 as development environment (which is a rewrite of MSYS and MinGW, based on newer Cygwin), which provides the build system for 3 targets: MSYS2 itself (for MSYS2 own utilities and ports of *NIX utilities), MinGW-w64/i686 and MinGW-w64/x86_64.

While the MinGW-w64 targets share most of the packages, this is not the case with the MSYS2 target.

Which one of the 3 possible cmake commands is needed to generate the suitable makefiles, when I want to target MinGW-w64/i686?

cmake -G "Unix Makefiles" .  ; under Unix / OS X / Cygwin
cmake -G "MSYS Makefiles" .  ; under MSYS/MinGW
cmake -G "MinGW Makefiles" . ; under (plain) MinGW
vhelin commented 6 years ago

I have to say that I have no idea. Have you tried out any of those three cmake commands, will they produce working executables?

On Sun, 15 Jul 2018 at 09:35, StarWolf3000 notifications@github.com wrote:

I'm using MSYS2 as development environment (which is a rewrite of MSYS and MinGW, based on newer Cygwin), which provides the build system for 3 targets: MSYS2 itself (for MSYS2 own utilities and ports of *NIX utilities), MinGW-w64/i686 and MinGW-w64/x86_64.

While the MinGW-w64 targets share most of the packages, this is not the case with the MSYS2 target.

Which one of the 3 possible cmake commands is needed to generate the suitable makefiles, when I want to target MinGW-w64/i686?

cmake -G "Unix Makefiles" . ; under Unix / OS X / Cygwin cmake -G "MSYS Makefiles" . ; under MSYS/MinGW cmake -G "MinGW Makefiles" . ; under (plain) MinGW

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/vhelin/wla-dx/issues/186, or mute the thread https://github.com/notifications/unsubscribe-auth/AGHtUgocEv3bVa8HeMIVymkBUY0IAQqrks5uGuLEgaJpZM4VQImV .

cr1901 commented 6 years ago

I use MSYS Makefiles for MinGW (or Ninja w/ CC and CXX set manually). This implies you're running cmake at the bash prompt.

Neui commented 6 years ago

MSYS2 is a fork of Cygwin, so "Unix Makefiles" should work.

It seems the "MSYS Makefiles" version seems to include more windows paths to search from and so seems to be designed for MSYS 1.0.

StarWolf3000 commented 6 years ago

It seems to build just fine with both Unix Makefiles and MSYS Makefiles. It's currently running under GCC 7.x, so there are lots of warnings regarding -wformat-overflow, but the tools build just fine regardless of those warnings. The results are around 500 kb. When running run_unit_tests.sh, wla-65816 will halt at the linker_test at wla-65816 -l test.lib test.s, so I have to kill it from the processes to let the tests continue.

vhelin commented 5 years ago

I just installed MSYS2, and compiled the latest WLA DX sources (cmake -G "Unix Makefiles"), ran run_unit_tests.sh, all worked just fine... linker_test/wla-65816 and test.s halts, but it asks for input. After I give it what it needs (a name for the program) it continues and finishes without errors...

StarWolf3000 commented 5 years ago

Maybe add some hint to the unit test, that it requests a filename? Without any indication, that its just waiting there for input, most would assume it hangs at this point.

Also is sphinx required or is it just for generating docs? (I'm trying to find the corresponding MSYS2/MinGW packages for it).

Neui commented 5 years ago

Also is sphinx required or is it just for generating docs?

Just for generating docs. It'll auto-disable when it couldn't find sphinx at the initial configure time. (Set GEN_DOC to ON to generate it, or GEN_DOC to OFF to not generate it)

(I'm trying to find the corresponding MSYS2/MinGW packages for it)

Might be easier when you use pip. The package is usually called python3-sphinx and/or python-sphinx. In MSYS2, there is mingw-w64-x86_64-python3-sphinx (and other variations), however I didn't tested these.

vhelin commented 5 years ago

On Mon, Dec 17, 2018 at 9:24 AM StarWolf3000 notifications@github.com wrote:

Maybe add some hint to the unit test, that it requests a filename? Without any indication, that its just waiting there for input, most would assume it hangs at this point.

When you compile that file it'll print the question into console, at least it should. :) If it doesn't, then there's something wrong...

Also is sphinx required or is it just for generating docs? (Also I'm trying to find the corresponding MSYS2/MinGW packages for it).

I installed MSYS2 without sphinx, and when I compiled WLA DX it didn't generate any documentation...

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/vhelin/wla-dx/issues/186#issuecomment-447746949, or mute the thread https://github.com/notifications/unsubscribe-auth/AGHtUgM5WRFvXnSdZtzwfUbTVU_vpZJzks5u50aTgaJpZM4VQImV .

StarWolf3000 commented 5 years ago

This is what happens at this point (the cursor is blinking, but no question is shown): Screenshot

It should be noted, that I don't use the work-in-progress version 9.8, but the stable release 9.7 (as you can see from my title bar)

vhelin commented 5 years ago

Here's what happens on my laptop (MSYS2, but Cygwin gives the same output):

msys2-wla

StarWolf3000 commented 5 years ago

I've updated my comment, I'm not using the latest work-in-progress 9.8, but release 9.7, so no export from master branch.

vhelin commented 5 years ago

I don't think that test has changed in many years, should also ask for the program name also in 9.7... Does your test.s look like this?

.DEFINE TESB 1 .EXPORT TESB

.SECTION "test" test_00: NOP .ENDS

.PRINTT "what's the name of this program? " .INPUT INFO

.SECTION "information" .DB INFO .ENDS

StarWolf3000 commented 5 years ago

Yes, with date from April 17 2018: Screenshot

vhelin commented 5 years ago

Here's what .PRINTT does in the end:

if (quiet == NO)
  printf("%s", t);

Looking at your screenshot, wla-65816 is not running in quiet mode, so that printf() then is somehow directed somewhere else than your shell... ???

StarWolf3000 commented 5 years ago

Looking at your screenshot, wla-65816 is not running in quiet mode, so that printf() then is somehow directed somewhere else than your shell... ???

It shouldn't actually, but I found something interesting: Scrolling back after giving a filename and having it finish, I found that the question was asked after inputting the "answer" (I chose test):

131037 unused bytes of total 131072.
Total 131072 additional bytes (from headers and footers).
Total size 262144 bytes.
wla-65816 -l test.lib test.s
test
what's the name of this program? wlalink -v -S linkfile result.smc
Free space at $0037-$003f.
Free space at $0043-$05ff.

My shell is bash (MSYS2 default), but the unit tests spawn sh.

vhelin commented 5 years ago

Bash buffered that printf() and outputted it after the input? Could also be that stdout is buffered... ? I'll add stdout flushing to 9.8a...

If you want to test it with your 9.7, then make sure PRINTT handling in pass_1.c ends to this:

if (quiet == NO) {
  printf("%s", t);
  fflush(stdout);
}

return SUCCEEDED;

StarWolf3000 commented 5 years ago

I have added that line to pass_1.c (as line 6601), and after rebuilding all binaries and running the tests, I finally get:

wla-65816 -l test.lib test.s
what's the name of this program?

with the cursor blinking after the question mark. So yeah, seems flushing is somehow required.

vhelin commented 5 years ago

Great! I've never needed such flushing before, but it seems that you'll have to do it for the code to work 100% all the time. :)

cr1901 commented 5 years ago

I've never needed such flushing before.

Typically, stdout is line-buffered. So including \n would've also done the trick. But tbh, I assume that's not what you wanted, and MSYS2's C stdlib buffering can interact badly with bash for some reason.