Re: [cc65] Universal Makefile: Some advanced magic wanted?

Hi,

> Hm, this may sound interesting but I am not fully convinced. Why (less important first)?

I see.

> - I personally never wanted to type more than make [install|clean|..]

What's the alternative? Editing the Makefile to adjust CFLAGS and
friends to your needs? Then you can as well edit it to include a line
OPTIONS=... and still have the benefit of not having to fiddle with
the flags directly.

Be honest: Every time you use a new toolchain you read the docs,
figure out the flags you like, write them in some Makefile - and after
some weeks/months you don't know anymore what they mean so you just
c&p them from one Makefile to the next...

However I think the real idea behind a Universal Makefile is that it
doesn't serve as a template but rather as something to be considered
r/o. Otherwise you wouldn't need the
name-the-program-like-the-directory trick. This way you define WHAT to
build. But still you need a way to control HOW to build it. And there
OPTIONS kicks in.

Anyway beside setting OPTIONS on the make cmdline you can set an
environment variable - or you can have a file named i.e.
Makefile.options containing one line saying

OPTIONS=optspeed,mapfile

and then have the Makefile contain a

-include Makefile.options

but that can admittedly be done the same way with a file containing
multiple lines for setting CFLAGS and friends.

> - Makefile will get more complex and may possibly become less readable, which may hinder its usability as a starting point for more complex ones

Most likely I'm to biased here: I'd say that even without fully
understanding how the code I proposed here actually works it is clear
what it wants to do - and that it can just be removed if not desired.
A meaning comment could support that.

> - Those options will have to get hardcoded, and (in case we ever convince Uz to put it into base) will have to be maintained along with the toolset, and in (quite possible) case it gets forgotten/omitted when some changes to the options happen (unlikely but still possible) the users may get unpredictable results of the type you wrote you wanted to avoid

From my experience the cc65 toolchain flags are very stable. The
incompatible change with --create-dep is really an expeption to the
rule.

> Having written all that - it still looks tempting. And I also like the $(REMOVES) idea a lot. Hm, if it was done in an elegant way with the last two points above in mind... thinking aloud.. like with things being easily configurable somewhere at the top and disabled by default, with clear messages... hm ;-)

After all it's just a proposal. If you really think the current
Makefile is aready the sweet spot of functionality vs. complexity then
this is fine with me. Therefore the '?' in the title of my original
posting...

Regards,
Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.