New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ALIGN to .RAMSECTIONs #42

Closed
vhelin opened this Issue Aug 2, 2015 · 34 comments

Comments

Projects
None yet
4 participants
@vhelin
Owner

vhelin commented Aug 2, 2015

.SECTIONs have ALIGN, but .RAMSECTIONs don't.

@vhelin vhelin added the enhancement label Aug 2, 2015

@vhelin vhelin self-assigned this Aug 2, 2015

@vhelin

This comment has been minimized.

Show comment
Hide comment
@vhelin

vhelin Aug 3, 2015

Owner

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.

Owner

vhelin commented Aug 3, 2015

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.

@nicklausw

This comment has been minimized.

Show comment
Hide comment
@nicklausw

nicklausw Aug 3, 2015

Contributor

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.

Contributor

nicklausw commented Aug 3, 2015

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.

@vhelin

This comment has been minimized.

Show comment
Hide comment
@vhelin

vhelin Aug 3, 2015

Owner

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
#42 (comment).

Owner

vhelin commented Aug 3, 2015

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
#42 (comment).

@Ramsis-SNES

This comment has been minimized.

Show comment
Hide comment
@Ramsis-SNES

Ramsis-SNES Aug 10, 2015

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. :-)

Ramsis-SNES commented Aug 10, 2015

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. :-)

@cr1901

This comment has been minimized.

Show comment
Hide comment
@cr1901

cr1901 Aug 10, 2015

Collaborator

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.

Collaborator

cr1901 commented Aug 10, 2015

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.

@nicklausw

This comment has been minimized.

Show comment
Hide comment
@nicklausw

nicklausw Aug 10, 2015

Contributor

What errors is win32_good.bat making?

Contributor

nicklausw commented Aug 10, 2015

What errors is win32_good.bat making?

@vhelin

This comment has been minimized.

Show comment
Hide comment
@vhelin

vhelin Aug 10, 2015

Owner

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
#42 (comment).

Owner

vhelin commented Aug 10, 2015

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
#42 (comment).

@nicklausw

This comment has been minimized.

Show comment
Hide comment
@nicklausw

nicklausw Aug 10, 2015

Contributor

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.

Contributor

nicklausw commented Aug 10, 2015

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.

@Ramsis-SNES

This comment has been minimized.

Show comment
Hide comment
@Ramsis-SNES

Ramsis-SNES Aug 11, 2015

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!

Ramsis-SNES commented Aug 11, 2015

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!

@vhelin

This comment has been minimized.

Show comment
Hide comment
@vhelin

vhelin Aug 11, 2015

Owner

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
#42 (comment).

Owner

vhelin commented Aug 11, 2015

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
#42 (comment).

@nicklausw

This comment has been minimized.

Show comment
Hide comment
@nicklausw

nicklausw Aug 11, 2015

Contributor

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?

Contributor

nicklausw commented Aug 11, 2015

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?

@cr1901

This comment has been minimized.

Show comment
Hide comment
@cr1901

cr1901 Aug 13, 2015

Collaborator

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.

Collaborator

cr1901 commented Aug 13, 2015

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.

@vhelin

This comment has been minimized.

Show comment
Hide comment
@vhelin

vhelin Aug 13, 2015

Owner

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
#42 (comment).

Owner

vhelin commented Aug 13, 2015

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
#42 (comment).

@Ramsis-SNES

This comment has been minimized.

Show comment
Hide comment
@Ramsis-SNES

Ramsis-SNES Aug 14, 2015

I can't seem to locate either unix.sh or win32.bat anymore. Aren't these still supposed to be in the root directory?

Ramsis-SNES commented Aug 14, 2015

I can't seem to locate either unix.sh or win32.bat anymore. Aren't these still supposed to be in the root directory?

@cr1901

This comment has been minimized.

Show comment
Hide comment
@cr1901

cr1901 Aug 14, 2015

Collaborator

unix.sh and win32.bat are gone. Use CMake to build unless your platform doesn't support it. Read INSTALL for more details.

Collaborator

cr1901 commented Aug 14, 2015

unix.sh and win32.bat are gone. Use CMake to build unless your platform doesn't support it. Read INSTALL for more details.

@Ramsis-SNES

This comment has been minimized.

Show comment
Hide comment
@Ramsis-SNES

Ramsis-SNES Aug 14, 2015

Sorry for being an idiot (obviously), but INSTALL tells me to use some win32.bat file.

ce872ef

Ramsis-SNES commented Aug 14, 2015

Sorry for being an idiot (obviously), but INSTALL tells me to use some win32.bat file.

ce872ef

@cr1901

This comment has been minimized.

Show comment
Hide comment
@cr1901

cr1901 Aug 14, 2015

Collaborator

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.

Collaborator

cr1901 commented Aug 14, 2015

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.

@Ramsis-SNES

This comment has been minimized.

Show comment
Hide comment
@Ramsis-SNES

Ramsis-SNES Aug 14, 2015

What ...?

Okay, whatever. Goodbye, WLA DX.

Ramsis-SNES commented Aug 14, 2015

What ...?

Okay, whatever. Goodbye, WLA DX.

@cr1901

This comment has been minimized.

Show comment
Hide comment
@cr1901

cr1901 Aug 14, 2015

Collaborator

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?

Collaborator

cr1901 commented Aug 14, 2015

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?

@vhelin

This comment has been minimized.

Show comment
Hide comment
@vhelin

vhelin Aug 14, 2015

Owner

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
#42 (comment).

Owner

vhelin commented Aug 14, 2015

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
#42 (comment).

@cr1901

This comment has been minimized.

Show comment
Hide comment
@cr1901

cr1901 Aug 14, 2015

Collaborator

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.

Collaborator

cr1901 commented Aug 14, 2015

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.

@vhelin

This comment has been minimized.

Show comment
Hide comment
@vhelin

vhelin Aug 14, 2015

Owner

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
#42 (comment).

Owner

vhelin commented Aug 14, 2015

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
#42 (comment).

@cr1901

This comment has been minimized.

Show comment
Hide comment
@cr1901

cr1901 Aug 14, 2015

Collaborator

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.

Collaborator

cr1901 commented Aug 14, 2015

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.

@vhelin

This comment has been minimized.

Show comment
Hide comment
@vhelin

vhelin Aug 14, 2015

Owner

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
#42 (comment).

Owner

vhelin commented Aug 14, 2015

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
#42 (comment).

@cr1901

This comment has been minimized.

Show comment
Hide comment
@cr1901

cr1901 Aug 14, 2015

Collaborator

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.

Collaborator

cr1901 commented Aug 14, 2015

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.

@vhelin

This comment has been minimized.

Show comment
Hide comment
@vhelin

vhelin Aug 15, 2015

Owner

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
#42 (comment).

Owner

vhelin commented Aug 15, 2015

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
#42 (comment).

@Ramsis-SNES

This comment has been minimized.

Show comment
Hide comment
@Ramsis-SNES

Ramsis-SNES Aug 15, 2015

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:

errors1

It'll create an CMakeCache.txt file anyway, so when I run the command again, CMake will do its job just fine apparently:

errors2

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). :)

Ramsis-SNES commented Aug 15, 2015

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:

errors1

It'll create an CMakeCache.txt file anyway, so when I run the command again, CMake will do its job just fine apparently:

errors2

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). :)

@vhelin

This comment has been minimized.

Show comment
Hide comment
@vhelin

vhelin Aug 15, 2015

Owner

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
#42 (comment).

Owner

vhelin commented Aug 15, 2015

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
#42 (comment).

@Ramsis-SNES

This comment has been minimized.

Show comment
Hide comment
@Ramsis-SNES

Ramsis-SNES Aug 15, 2015

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 )

Ramsis-SNES commented Aug 15, 2015

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 )

@vhelin

This comment has been minimized.

Show comment
Hide comment
@vhelin

vhelin Aug 15, 2015

Owner

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
#42 (comment).

Owner

vhelin commented Aug 15, 2015

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
#42 (comment).

@cr1901

This comment has been minimized.

Show comment
Hide comment
@cr1901

cr1901 Aug 15, 2015

Collaborator

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.

Collaborator

cr1901 commented Aug 15, 2015

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.

@Ramsis-SNES

This comment has been minimized.

Show comment
Hide comment
@Ramsis-SNES

Ramsis-SNES Aug 15, 2015

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. :/

Ramsis-SNES commented Aug 15, 2015

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. :/

@vhelin

This comment has been minimized.

Show comment
Hide comment
@vhelin

vhelin Oct 25, 2015

Owner

Guys, can we close this one?

Owner

vhelin commented Oct 25, 2015

Guys, can we close this one?

@Ramsis-SNES

This comment has been minimized.

Show comment
Hide comment
@Ramsis-SNES

Ramsis-SNES Oct 27, 2015

No objection from my side. :-)

Ramsis-SNES commented Oct 27, 2015

No objection from my side. :-)

@vhelin vhelin closed this Oct 29, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment