Move hard coded GEN_2_GRAPHICS to Makefile as a build parameter

[etdv-thevoid]

Removes the hard coded constant GEN_2_GRAPHICS out of includes.asm and replaces it with a RGBASM flag _GEN_2_GRAPHICS.

Adds the ability to run make run with GFX=2 to build the ROMs with Gen 2 Graphics. And GFX=1 to build with Gen 1 Graphics.

To maintain current behavior, makefile defaults to Gen 2 Graphics if no option is included when running make.

Allows building both versions from the command line without editing .asm files.

Improves modularity of code base for downstream forks and projects.

[dannye]

This definitely has its advantages, but it also has the downside when you run make GFX=2 immediately followed by make GFX=1 and it misleadingly reports:

make: Nothing to be done for 'all'.

I'll sleep on this and try to think of a way to get the best of both worlds.

The current approach of using includes.asm has the benefit that when you change the constant value, you immediately trigger a full rebuild since includes.asm is a dependency of every other file.

[etdv-thevoid]

This definitely has its advantages, but it also has the downside when you run make GFX=2 immediately followed by make GFX=1 and it misleadingly reports:

make: Nothing to be done for 'all'.

I'll sleep on this and try to think of a way to get the best of both worlds.

The current approach of using includes.asm has the benefit that when you change the constant value, you immediate trigger a full rebuild since includes.asm is a dependency of every other file.

Would it be better and more maintainable to instead have makefile targets for each? Maybe something like this?

roms := \
	pokered.gbc \
	pokeblue.gbc \
	pokeblue_debug.gbc \
	pokered_gen1gfx.gbc \
	pokeblue._gen1gfx.gbc \
	pokeblue_gen1gfx_debug.gbc \

Etc. with the rest of the build.

Could potentially make updates from base pokered annoying though.

[dannye]

Would it be better and more maintainable to instead have makefile targets for each? Maybe something like this?

Sounds pretty tedious.

I rather like the simplicity and reliability of the current system (but I recognize the pros and cons).