[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#837650: RFS: cf-python/1.3.1+dfsg.1-1 [ITP]



Hi Klaus

> I removed most of the offending content and added the information for the remaining stuff, namely two files of static sphinx content.

wonderful

> > 3)
> > 
> > something about: 
> > cf/um/umread/c-lib/Makefile
> > 
> > CC=gcc
> > 
> > such stuff is a no-go for my personal policy.
> > People might want to export CC=clang or whatever, and see it build with it.
> > 
> > Changing
> > CC=gcc
> > to CC?=gcc fixes this
> > (set if not already set)
> > the same applies to other stuff in that file.
> I incorporated all of the above.

wonderful!

> > $(LDFLAGS)<-- this should be at the end of the line, not at the begin, otherwise
> > you might see some libraries stripped just because the .o files needing them
> > are put after (this happens when wl-asneeded is used/default)

> Hm, GNU make disagrees with you here. The built-in rule for linking is
> $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH) $^ $(LOADLIBES) $(LDLIBS) -o $@

GNU make file seems to be wrong here then :)
how can you use LDFLAGS with CC?
you can use them only with $(LD) invocation.
Do you have any documentation here? I admit this seems wrong in many places, e.g.
LOADLIBES is something deprecated long time ago
LDLIBS is now mostly unused, and LIBS is used instead.
LDFLAGS is moved at the bottom, but only when LD is invoked.

This seems to be the last showstopper, the other stuff looks good to me now :)
(and it might be that you are right and I'm wrong, in that case I'll sign and upload as-is, just
please enlighten me about this!)

thanks,

G.

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: