Re: [cc65] Please critique this makefile

On 2010-04-26, at 11:39, Oliver Schmidt wrote:

> 
> Sorry, I mixed up those two in the hurry. My idea was to set CC65_HOME
> empty like the other macros and then use ifeq like the other macros.
> That would give the user a good overview what macros are "input
> variables" to the Makefile. A Windows user exlusively using your
> Makefile coudl very well define CC65_HOME just there and not in the
> system environment...
> 

I see But what if it is actually present in the system environment and valid? (e.g. because CC65 is installed in a non-default location)? I think it is OK not to force users who have it already present in the system, to reenter it here.

>> http://zennon.internetdsl.pl/Makefile_20100426
> 
> Nice :-)
> 

Yeah - thanks for the core job on that! Now only the asm dependencies... :-)


> Another minor idea: The macro name CC65_TARGET came form the
> cross-toolchain Makefile in the cc65 docs. In this cc65-only Makefile
> you could name it just TARGET...

I like it as it is. It clearly says we are talking about CC65 target here. I can imagine different targets within one CC65 target for example.

>> I was still wondering if you could advice on elegant way for making e.g. the
>> .map (and possibly other stuff) optional rather than hardcoded in
>> $(PROGRAM): and clean:
> 
> I see your issue. The problem is that several options create
> additional files. So 'clean' needs to know them. And I considered it
> not elegant to have clean try to remove many well-known file
> extenstions used by the cc65 linker.
> 
> However given the way the Make is planned to use on could argue that
> deleting just every file in the "main" directory is acceptable like
> this
> 
> clean:
> 	rm -f * $(OBJECTS) $(DEPENDS)
> 	rmdir $(OBJECTDIR)

That would remove e.g. the Makefile itself ;-)

I was thinking about "rm $(PROGRAM)* but I still didn't like it. I would be rather looking for a way to determine what is generated by various targets and remove only those, but when thinking more, I believe it could even delete every possible files, even if they are not generated in the current setup / with current options.

> 
> Then there would be no "incompatibility" between any file-generating
> linker flags and the clean goal. Someone who wants a mapfile could
> then just say so in his LDFLAGS.
> 
> That brings me to another quirk I introduced. The three lines
> 
> CFLAGS  :=
> ASFLAGS :=
> LDFLAGS :=
> 
> should rather read
> 
> CFLAGS  =
> ASFLAGS =
> LDFLAGS =
> 
> because then (and only then) something like
> 
> LDFLAGS = -m $@.map
> 
> is going to work.

Yup, I know.

Regards,

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