Re: [sdcc-devel] pic16 library extension change

[Raphael N. <rn...@we...>]

Dear Borut,

> I saw that you changed the pic16 library file extension from .lib to .a. 
> I don't know why you did it, I assume to simplify the build of pic16 
> libraries using autotools.

That's correct. I found no way to create libraries with the .lib extension.

> Some problems arise from this change:
> - backward compatibility for users: they have to change makefiles, 
> project files, batch scripts, ... for their old projects
> - I think that the default extension for pic16 libraries provided from 
> Microchip is .lib, so we are not compatible

Yep, you are right. I always thought LIBsdcc.LIB was a bit silly and
thus got the idea of adopting the Unix convention, using .a for
statically linked libraries/archives of .o files, but compatibility
bites us here. I'll revert it.

> I propose to revert this change with a simple patch, which changes the 
> extension while copying libraries to build/pic16 directory:
> 
> Index: Makefile.in
> ===================================================================
> --- Makefile.in    (revision 5216)
> +++ Makefile.in    (working copy)
> @@ -328,7 +328,7 @@
>  port-specific-objects-pic16:
>      -if [ -f $(PORT)/Makefile ]; then \
>        $(MAKE) -C $(PORT); \
> -      cp -f $(PORT)/*/lib*.a $(PORTDIR); \
> +      for i in $$(ls pic16/*/lib*.a); do cp -f $$i $(PORTDIR)/$$(basename $$i .a).lib; done; \
>        cp -f $(PORT)/*/crt0*.o $(PORTDIR); \
>      fi

That's not sufficient: SDCC itself (src/pic16/glue.c?) has to be changed
to link with .lib rather than .a files again.

BTW: Is the "$$(ls ...)" required, i.e., wouldn't "for i in
$(PORT)/*/lib*.a; do" work as well as it does in the surrounding lines?!?

> The better solution would be to generate the libraries with .lib 
> extension...

Agreed; so, if anybody tells me how to teach the Autotools to do "the
right thing" ...

Regards,
Raphael