Closed StarWolf3000 closed 5 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 .
I use MSYS Makefiles
for MinGW (or Ninja
w/ CC
and CXX
set manually). This implies you're running cmake
at the bash
prompt.
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.
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.
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...
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).
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.
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 .
This is what happens at this point (the cursor is blinking, but no question is shown):
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)
Here's what happens on my laptop (MSYS2, but Cygwin gives the same output):
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.
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
Yes, with date from April 17 2018:
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... ???
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.
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;
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.
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. :)
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.
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?