Re: [cc65] Search path priority

Hi Uz,

Ullrich von Bassewitz writes:

> On Mon, Oct 22, 2012 at 04:13:37PM +0200, Uffe Jakobsen wrote:
> > As far as I can see that works for cc65 and ca65 - but not ld65.
> >
> > With ld65 I cannot see an option that makes it forget its compiled
> > paths - or did I miss anything ?
>
> Yes, you did miss something. For ld65 it is not necessary, because you  
> specify
> libraries and object files on the command line (not in source files). Just
> name the libraries with the correct path and they will be used.
>

My point is that Makefiles shouldn't be filled with "hardcoded" info that  
the compiler should be able to deduct by itself from an environment variable  
or fallback to its defaults - in the mentioned order.

> > If I understand you correct:
> > This requires every developer to be aware of this "feature" - and
> > plaster his makefiles with options compensating for the current
> > search path approach - if not his project will not work properly in
> > situations that I described in the initial email.
>
> While your idea requires the developer to be aware of the feature and switch
> environment variables. I cannot see why this is so advantageous.
>

It is rather common for *nix programs to react upon enviroment variables -if  
setup - and fallback to defaults if not setup - cc65 does the opposite.

> > Is there any compelling reason for not changing the search path
> > priority as suggested ?
>
> I have no problems changing the search path algorithm (again) if this is a
> popular request. But I doubt that this has real advantages, because it
> requires users with more than one compiler version to adjust the environment
> variables and this is as error prone as any other solution.
>

With multiple compilers installed this construction will not work:

ld65 .... --lib c64.lib

hmmm...Okay... - let us try this then:

ld65 .... -L $(LIB_DIR) --lib c64.lib

Nope that will not work either.......

Because of the current search patch - supplying the -L $(LIB_DIR) has no  
meaning at all for standard libs - ld65 will still find the wrong standard c64.lib -  
that goes for all standard libraries that are shipped with cc65. This seems  
just plain wrong to me.
 
Users with more than one compiler would have to write something like this in  
their Makefile for ld65 even to find the right standard libraries shipped  
with cc65 distribution:

ld65 .... --lib $(LIB_DIR)/c64.lib

If you want to make your project flexible and portable - the job of  
establishing what LIB_DIR should be setup to in order to consider both  
LD65_LIB, CC65_HOME and still fallback in case of no env vars - this will  
require parts of the same search path logic that ld65 already has -The  
difference is that is you need to implement it into every makefiles of your  
the project. I'm sorry but I cannot help feeling that this is wrong - such  
logic should not go into the makefiles.

My point here is that it should not be necessary to explicitly tell the  
compiler where is should find its own *standard* libraries - why not let it  
rely on $LD65_LIB or  $CC65_HOME/lib if setup - and then revert to default  
if the lib is not found.

Now this command would work inside your makefile

ld65 .... --lib c64.lib

and your LD65_LIB and CC65_HOME environment would assist ld65 in its search  
for its standard libraries - if setup. This enables maximum flexibility and  
coexistance - and keeps hardcoded mumbo-jumbo out of the Makefiles


Kind regards Uffe Jakobsen


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