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

Hi Uz,

> That's not true, but not a problem, since it is not much code, and the list of
> files is kept for other purposes already (they're written to the object files).

Nice :-)

> A more serious question is how to handle --create-dep on the cl65 level? The
> simplest way would be to add something like --asm-create-dep, which is
> explicitly passed to the assembler. But what if --create-dep is specified when
> assembling files with cl65? On the other side, cl65 could try to be smart
> (in fact, I could try to teach cl65 how to be smart :-), but often, trying to
> be smart doesn't work as expected :-)

I must admit that I can't follow here. Where's the issue with using
--create-dep both for the compiler and assembler? Are we talking about
the scenario of someone using cl65 who want's .u files for C sources
but not for asm sources (or the other way round)? That scenario seems
by far obscure enough to say that's a case for calling the underlying
tools separately.

However The issue I see (like silverdr) is potential overwriting of
cc65-generated .u files with ca65-generated .u files. Either one could
do what silverdr describes, or one could have _ONLY_ ca65 generate .u
files. Then cc65 would embed it's dependency information in some
format in the generated .s file. And ca65 would write it out. One
would however have to distinguish between several scenarios...

a) Individual calls to compile a C file:

make calls cc65 with --create-dep, it write its <file>.s: <file>.c
<incl>.h to the .u file (it embeds them as well into the .s file where
they don't hurt).

make calls ca65 without --create-dep as the cc65 generated .s files
don't have includes anyway.

b) Assemble an asm file:

make calls ca65 with --create-dep, it write its <file>.o: <file>.s
<incl>.inc to the .u file.

c) Compile a C file through cl65:

make calls cl65, which calls cc65 without --create-dep, it only embeds
its dependencies into the .s file.

make calls cl65 which calls ca65 with --create-dep, it finds the
embedded dependencies and writes <file>.o: <file>.c <incl>.h to the .u
file.

I certainly understand if you consider this approach too much effort
"just for" dependency management. I just wanted to point out the from
my perspective best way - as it allows cl65 users to really "forget
about" the intermediate .s files. Otherwise a .u file postprocessing
is always necessary.

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