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

On 2010-05-03, at 21:40, Oliver Schmidt wrote:

Well - for the beginning - please don't get me wrong! I don't try to shoot the idea down. I am a big fan of your make voodoo skills, and this one proves them too. Now to the point I tried to think aloud in my previous post - if that can be done in a way that will allow people who are far beyond you in their magicians careers to quickly (or better: not have to) understand what are the spells in there, then it is OK. If the flags are grouped logically around the beginning, and if the comments could also tell that e.g. "the options here are valid as of cl65 version x.yy.zz, please verify and adapt to the version you are using" or something along those lines - then it should be a good compromise, which still undoubtedly would add value.

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

Right.

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

I see it a bit differently. It should allow me (others) to kick-start a project without thinking too much of anything else than how to code this or that in C. Certainly I don't want to think how to create a Makefile, which may be as complex as the quick test I want to do in C and/or ASM e.g. just as a proof of concept for some idea. I just want to type "make" and there it goes. *BUT* it would also be great if I didn't have to write my own Makefile from scratch once the project grows and some more specific needs arise.

> This way you define WHAT to
> build. But still you need a way to control HOW to build it. And there
> OPTIONS kicks in.

My previous paragraph does not exclude that. Again - I wanted to put attention on HOW to do this. I might not have been completely clear but it was not IF to do it. Just so that at least the two last points I raised are taken into account.

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

Yes - but you immediately noticed what I meant here.

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

And an interesting and tempting one, especially knowing that you can do such stuff with little finger of your left hand ;-) Let me try be more clear now: the answet is "yes, please - only have the two points in head when structuring and commenting it".

-- 
SD!

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