Closed vhelin closed 9 years ago
Ok, can someone verify using the latest sources that this has been done? :) I added a test for it (ram_sections under examples/z80) but still, the more tests & testing the better.
I would but I don't even know what ALIGN does. Last I checked, the docs said "you can also align sections" and that was it.
Hmm true, I'll need to make the docs clearer about it.
On Mon, Aug 3, 2015 at 9:02 PM, nicklausw notifications@github.com wrote:
I would but I don't even know what ALIGN does. Last I checked, the docs said "you can also align sections" and that was it.
— Reply to this email directly or view it on GitHub https://github.com/vhelin/wla-dx/issues/42#issuecomment-127353296.
Please do. :-)
BTW, I can't compile WLA under MinGW anymore all of a sudden. The win32 file mentioned in INSTALL simply doesn't exist anymore. :-( Using the one I'd saved from the last snapshot (dating June 21st) doesn't help either. Instead, it complains about missing "make clean" rules (even though the "clean" rule appears to be present in each and every makefile that's relevant).
And no, the new win32_good.bat doesn't do the job either, not even in a plain DOS prompt. It yields even more errors than said older win32 script.
The Linux binaries compiled just fine, BTW. So I'm at a loss here, and would appreciate any help. :-)
New install system is under construction and uses CMake (save for the Amiga and MSDOS targets).
The command: cmake -G "MinGW Makefiles" /path/to/wla
should get you on your way.
What errors is win32_good.bat making?
I'm using CygWin here in Windows 10, and if I delete a file called MAKEFILE (all upper case) from the project root I can run "./unix.sh 1" and it'll work. :)
On Tue, Aug 11, 2015 at 1:57 AM, nicklausw notifications@github.com wrote:
What errors is win32_good.bat making?
— Reply to this email directly or view it on GitHub https://github.com/vhelin/wla-dx/issues/42#issuecomment-129640252.
Update, I think I know what your problem is: my bad habit of using make instead of mingw32-make.
Not sure if this is good practice but when installing mingw32, I always make a copy of mingw32-make called make just for the sake of compatibility. Perhaps that'll help.
Okay, I got my Windows binaries to compile by following Ville's advice AND replacing all the "unix" strings in the unix.sh file with "win32". Phew!
Mr. Jones and/or nicklausw, if you modify the build scripts, could you please keep the INSTALL file also up to date so that people (who don't read these forum posts) will know how to build WLA DX? Thanks. :)
For me (I'm running Cygwin here) "cmake -G "MinGW Makefiles"" gave:
CMake Error: Could not create named generator MinGW Makefiles
... but "cmake CMakeLists.txt" and after that "make" built me the binaries and something extra as well... FYI, I have zero experience on cmake...
On Tue, Aug 11, 2015 at 7:51 PM, Ramsis notifications@github.com wrote:
Okay, I got my Windows binaries compile by following Ville's advice AND replacing all the "unix" strings in the unix.sh file with "win32". Phew!
— Reply to this email directly or view it on GitHub https://github.com/vhelin/wla-dx/issues/42#issuecomment-129965694.
It seems I've deleted something I shouldn't have...if this is true then sorry.
Can someone on Windows try running win32_good.bat with the makes replaced with mingw32_makes?
WLA main branch now officially uses CMake. INSTALL instructions updated with information on how to use CMake and get back legacy Makefiles (legacy_mk branch). win32_good.bat renamed win32.bat.
Cleaning everything up took longer than I expected, no thanks to gratuitous merge issues.
Great work, thank you! :)
On Thursday, August 13, 2015, William D. Jones notifications@github.com wrote:
WLA main branch now officially uses CMake. INSTALL instructions updated with information on how to use legacy Makefiles (legacy_mk branch). win32_good.bat renamed win32.bat.
Cleaning everything up took longer than I expected, no thanks to gratuitous merge issues.
— Reply to this email directly or view it on GitHub https://github.com/vhelin/wla-dx/issues/42#issuecomment-130832099.
I can't seem to locate either unix.sh or win32.bat anymore. Aren't these still supposed to be in the root directory?
unix.sh and win32.bat are gone. Use CMake to build unless your platform doesn't support it. Read INSTALL for more details.
Sorry for being an idiot (obviously), but INSTALL tells me to use some win32.bat file.
https://github.com/vhelin/wla-dx/commit/ce872efc4020ad1895e46881fd2a36702aad1c9d
That's part of the Legacy section (available by checking out the legacy_mk branch)- it is for completeness of documentation only. You should not be using win32.bat.
What ...?
Okay, whatever. Goodbye, WLA DX.
Not sure why you just can't install CMake... Sorry you have to deal with Makefile hell- believe me, I know- but this change was a long time coming. You'll notice that the INSTALL file has two sections. CMake and Legacy, denoted by a colon (:) after each.
I moved the win32.bat and unix.sh to a separate git branch called "legacy_mk" to encourage ppl to use CMake (CMakeLists.txt) to generate the Makefiles automatically. Development from here on out will assume that most end users will use the CMake software to compile WLA-DX.
Does that make more sense now?
Hmm I have a question about the INSTALL file:
...
"$MAKE_TYPE can be any Makefile type that CMake supports."
...
What's a Makefile type? Are there other Makefiles than... a makefile? FYI, after reading the CMake section of INSTALL file I still have no idea how to build WLA DX using cmake. :) Could all that be somehow contained in a simple script file (.sh for Unix-likes and .bat for MSDOS...)? :D
On Fri, Aug 14, 2015 at 9:31 PM, William D. Jones notifications@github.com wrote:
That's part of the Legacy section (available by checking out the legacy_mk branch)- it is for completeness of documentation only. You should not be using win32.bat.
— Reply to this email directly or view it on GitHub https://github.com/vhelin/wla-dx/issues/42#issuecomment-131203416.
Long ago, when Stuart Feldman invented make, Makefiles had a consistent syntax. Even Stuart Feldman's make supported wildcards and other goodies, but not conditional logic like if
and other things.
A number of software vendors f***ed this up by creating extensions to Stuart Feldman's syntax that were incompatible with each other, and either compiler-toolchain specific or OS-specific. One of the fallouts of this today is that it's difficult to write a "universal Makefile"- one that works on MSDOS, Unix, Windows, etc.
CMake is a Makefile wrapper language. It will generate Makefiles appropriate to your platform, but you (typically) need to tell it what type of Makefiles to generate, appropriate to your compiler and platform.
For Unix, cmake -G "Unix Makefiles" /path/to/wla
should be fine.
For Windows cmake -G "MSYS Makefiles" /path/to/wla
or cmake -G "MinGW Makefiles" /path/to/wla
or cmake -G "Nmake Makefiles" /path/to/wla
will do the trick.
After cmake generates the files, execute your build tool (nmake, make, etc) and WLA will be created.
I didn't add the CMake support. Someone else did, and I thought dealing with CMake was worth the trouble compared to my mess of the build system.
On Fri, Aug 14, 2015 at 9:51 PM, William D. Jones notifications@github.com wrote:
Long ago, when Stuart Feldman invented make, Makefiles had a consistent syntax.
A number of software vendors f***ed this up by creating extensions to Stuart Feldman's syntax that were incompatible with each other, and either compiler-toolchain specific or OS-specific. One of the fallouts of this today is that it's difficult to write a "universal Makefile"- one that works on MSDOS, Unix, Windows, etc.
CMake is a Makefile wrapper language. It will generate Makefiles appropriate to your platform, but you (typically) need to tell it what type of Makefiles to generate, appropriate to your compiler and platform.
For Unix, cmake -G "Unix Makefiles" /path/to/wla should be fine. For Windows cmake -G "MSYS Makefiles" /path/to/wla or cmake -G "MinGW Makefiles" /path/to/wla or cmake -G "Nmake Makefiles" /path/to/wla will do the trick.
I didn't add the CMake support. Someone else did, and I thought dealing with CMake was worth the trouble compared to my mess of the build system.
Thanks for the explanation. I went and added quick install instructions to INSTALL file, and cleaned it up a little - could you please check it out that I didn't make any mistakes? :) The Nmake part - I'm not so sure about it...
Also, would it be possible to have the Amiga build scripts in the main branch of WLA DX as we don't have new build scripts for Amiga (?).
And after I run "cmake -G "Unix Makefiles" ." in wla-dx folder, and "make" after that, this is what I get:
Ville@Lenovo-PC /cygdrive/c/Users/Ville/Documents/wla-dx $ ls -laF binaries/ total 3101 drwxrwx---+ 1 Ville None 0 Aug 14 21:59 ./ drwxrwx---+ 1 Ville None 0 Aug 14 22:10 ../ -rwxrwx---+ 1 Ville None 119 Jul 8 22:31 .gitignore -rwxrwxr-x+ 1 Ville None 83997 Aug 14 21:59 gen_GB.exe -rwxrwxr-x+ 1 Ville None 81949 Aug 14 21:59 gen_HUC6280.exe -rwxrwxr-x+ 1 Ville None 78365 Aug 14 21:59 gen_MCS6502.exe -rwxrwxr-x+ 1 Ville None 82973 Aug 14 21:59 gen_MCS6510.exe -rwxrwxr-x+ 1 Ville None 74781 Aug 14 21:59 gen_SPC700.exe -rwxrwxr-x+ 1 Ville None 85021 Aug 14 21:59 gen_W65816.exe -rwxrwxr-x+ 1 Ville None 80925 Aug 14 21:59 gen_WDC65C02.exe -rwxrwxr-x+ 1 Ville None 103453 Aug 14 21:59 gen_Z80.exe -rwxrwxr-x+ 1 Ville None 262858 Aug 14 21:59 wla-6502.exe -rwxrwxr-x+ 1 Ville None 267466 Aug 14 21:59 wla-6510.exe -rwxrwxr-x+ 1 Ville None 298001 Aug 14 21:59 wla-65816.exe -rwxrwxr-x+ 1 Ville None 266954 Aug 14 21:59 wla-65c02.exe -rwxrwxr-x+ 1 Ville None 72503 Aug 14 21:59 wlab.exe -rwxrwxr-x+ 1 Ville None 274279 Aug 14 21:59 wla-gb.exe -rwxrwxr-x+ 1 Ville None 273098 Aug 14 21:59 wla-huc6280.exe -rwxrwxr-x+ 1 Ville None 153454 Aug 14 21:59 wlalink.exe -rwxrwxr-x+ 1 Ville None 266735 Aug 14 21:59 wla-spc700.exe -rwxrwxr-x+ 1 Ville None 300871 Aug 14 21:59 wla-z80.exe*
What are those gen_*.exe -files? Do we need them?
— Reply to this email directly or view it on GitHub https://github.com/vhelin/wla-dx/issues/42#issuecomment-131207995.
No, you don't need the gen files... they just are binaries used to generate the opcode lookup table arrays to speed up searching for the proper opcode (in case, e.g. alternate opcodes are added, the lookup tables need to be regenerated).
I need to fix that so they're either deleted or moved to an intermediate directory.
Just to make things simple for the end user, could those gen_*.exe -files be somehow autodeteled by the makefile scripts?
On Fri, Aug 14, 2015 at 10:18 PM, William D. Jones <notifications@github.com
wrote:
No, you don't need the gen files... they just are binaries used to generate the opcode lookup table arrays to speed up searching for the proper opcode (in case, e.g. alternate opcodes are added, the lookup tables need to be regenerated).
— Reply to this email directly or view it on GitHub https://github.com/vhelin/wla-dx/issues/42#issuecomment-131213207.
I'm sure they could, but I'd need to look up how it's done in CMake parlance. In the old system, it's not a big deal because intermediate files are all cleaned in between creating each assembler.
I spent a couple of hours checking out CMake, reading the docs etc., and modded the main CMakeLists.txt to delete the gen_* executables post wla-dx build. CMake surely looks pretty nice! :)
On Fri, Aug 14, 2015 at 10:22 PM, William D. Jones <notifications@github.com
wrote:
I'm sure they could, but I'd need to look up how it's done in CMake parlance. In the old system, it's not a big deal because intermediate files are all cleaned in between creating each assembler.
— Reply to this email directly or view it on GitHub https://github.com/vhelin/wla-dx/issues/42#issuecomment-131213833.
CMake is cool, and works great for me on Linux. However, it completely broke my MinGW setup, requiring me to wipe and reinstall it.
Still no luck -- I can't seem to compile WLA on MinGW anymore. Here are the error messages:
It'll create an CMakeCache.txt
file anyway, so when I run the command again, CMake will do its job just fine apparently:
But as you can see, the subsequent make
command fails.
What am I missing? Thanks for any hints (but please don't bother suggesting to use the legacy branch). :)
Crap. I've never used MinGW myself, just Cygwin in Windows. Would
cmake -G "MSYS Makefiles" .
work better? I don't know what that MSYS is, but when I Googled it I found out it had something to do with MinGW...
On Sat, Aug 15, 2015 at 8:24 PM, Ramsis notifications@github.com wrote:
CMake is cool, and works great for me on Linux. However, it completely broke my MinGW setup, requiring me to wipe and reinstall it.
Still no luck -- I can't seem to compile WLA on MinGW anymore. Here are the error messages:
[image: errors1] https://cloud.githubusercontent.com/assets/11965591/9290025/c0ddc972-4382-11e5-848a-21c751c0e305.png
It'll create an CMakeCache.txt file anyway, so when I run the command again, CMake will do its job just fine apparently:
[image: errors2] https://cloud.githubusercontent.com/assets/11965591/9290030/0ecb9ad8-4383-11e5-82c5-9971e857116a.png
But as you can see, the subsequent make command fails.
What am I missing? Thanks for any hints (but please don't bother suggesting the legacy branch). :)
— Reply to this email directly or view it on GitHub https://github.com/vhelin/wla-dx/issues/42#issuecomment-131402764.
Thanks, Ville! I tried that, and it returned this at first:
CMake Error: Error: generator : MSYS Makefiles
Does not match the generator used previously: MinGW Makefiles
Either remove the CMakeCache.txt file and CMakeFiles directory or choose a different binary directory.
Then I removed both CMakeCache.txt
and cmake_install.cmake
, tried it again, and it (plus the make procedure) seemed to work instantly. You're my hero!! :D
(Now let's just hope the build workflow won't change again tomorrow ... :p )
LOL, cool! :D
Perhaps I should really find out what happened, and update the INSTALL file accordingly. :)
And I too hope the CMake build system is here to stay for the next 10 years... :)
On Sat, Aug 15, 2015 at 8:37 PM, Ramsis notifications@github.com wrote:
Thanks, Ville! I tried that, and it returned this at first:
CMake Error: Error: generator : MSYS Makefiles Does not match the generator used previously: MinGW Makefiles Either remove the CMakeCache.txt file and CMakeFiles directory or choose a different binary directory.
Then I removed both CMakeCache.txt and cmake_install.cmake, tried it again, and it (plus the make procedure) seemed to work instantly. You're my hero!! :D
(Now let's just hope the build workflow won't change again tomorrow ... :p )
— Reply to this email directly or view it on GitHub https://github.com/vhelin/wla-dx/issues/42#issuecomment-131403739.
MSYS is a set of POSIX utilities that implements behavior closer to POSIX spec than Gnuwin32's implementation of coreutils, and also provides a bash implementation for Windows (Ramsis: I do find it curious you're using a plain sh and cmd.exe cannot be found within your shell session- but in any case, CMake is correct in assuming you meant to use MSYS because it found a sh implementation on your path).
For example, different characters are escaped in the MSYS sed compared to Gnuwin32's sed, and parsed paths are more POSIXy ("/c/" instead of "C:\") for the MSYS tools. Autoconf scripts are know to break on the Gnuwin32 sed (if the Gnuwin32 sed is on the Windows path first within a bash session), so the MSYS version is heavily preferred :P.
MinGW in general works fine without MSYS, but since so many people who use MinGW also likely have an MSYS environment, CMake provides Makefile generators for both, depending on your setup. At least, that's my logic :P.
FWIW, WLA also compiles correctly with CL.EXE, and Watcom C Compiler. It'll even create Visual Studio solutions if you run CMake from a Visual Studio Command Prompt!
"(Now let's just hope the build workflow won't change again tomorrow ... :p )" It won't. I made a mistake playing around with the build system so much. I just don't think that the portability of this project should be locked into the build system, and in this case, it still isn't. Use CMake if you have it, alternate Makefiles are provided if you don't.
MSYS is the standard shell installed with MinGW's recommended online-installer, so yeah, most people will use/have it. In fact, I wouldn't even know how to start a "pure" (i.e., non-MSYS) MinGW shell, if that's even possible. :/
Guys, can we close this one?
No objection from my side. :-)
.SECTIONs have ALIGN, but .RAMSECTIONs don't.