Re: [cc65] --create-dep for ca65?

Hi,

>> - The .d files don't need to be parsed for 'love' too, but I don't
>> think that optimization is worth the complication...

> Could you be so kind as to elaborate a bit?

ifneq ($(MAKECMDGOALS),clean)
-include $(OBJECTS:.o=.d)
endif

omits reading in the .d files if the given goal is known to not need
them - like 'clean'. The same is true for 'love'. But taking that into
account would mean moving away from a simple ifneq, which I don't
consider appropriate just for optimizing the performance of 'love' (at
least in the context of Makefiles ;-)

>> - '--create-full-deps' isn't necessary
>>
>> and turns the Makefile most
>> certainly useless for Windows users.

> Because of the absolute paths, I guess?

You're right. Path with colons just work in GNU Makefiles.

> I might sound ignorant so have mercy (I ditched my last Windows system some time in late 2002) but doesn't cygwin (that was what I recall I used to bring some common unix tools, including make itself, to Windows back then) take care of that? Doesn't it change the access from C:\dir0\dir1\file0 to something like /drives/c/dir0/dir1/file0 ?

You're right. But unfortunately this makes things in this scenario
even worse. cc65 isn't a Cygwin program and therefore writes "native"
Windows paths into the .d files. On the other hand 'make' is a Cygwin
program not understanding those paths (independently from the colon
problem).

>> Uz explicitly added the
>> capability to omit the system headers using --create-deps for this
>> reason.

> I thought it was more to avoid the mostly unnecessary overhead and clutter in the results.

Just avoiding that very small overhead for sure wouldn't have made Uz
change the code. Rather it was the option to avoid the weird hacks
necessary today on Windows / Cygwin.

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