Garance A Drosihn wrote: > Back in March I was working on an updated version of the net/cap > port, and I noticed this problem with CFLAGS in /etc/make.conf vs > CFLAGS in the makefile of a port. (So I am pretty sure this issue > has nothing to do with the recent changes to `make'.) Sure. I even tested it with make(1) from 4.7. This has been there for ages. > What I ended up doing was changing the net/cap/Makefile to set > CAP_CFLAGS instead of CFLAGS. The distributed net/cap source has > a bunch of Makefile.m4 files which are used to generate the real > makefiles, and those Makefile.m4 files were already adding a bunch > of values to CFLAGS. So, I changed a line (in net/cap/Makefile) > from: > > ${FIND} ${WRKSRC} -name Makefile.m4 \ > -exec ${REINPLACE_CMD} \ > -e 's/CFLAGS=/CFLAGS+=/' \{\} \; > > to: > > ${FIND} ${WRKSRC} -name Makefile.m4 \ > -exec ${REINPLACE_CMD} \ > -e "s/CFLAGS=/CFLAGS+=${CAP_CFLAGS} /" \{\} \; Jup, but this is hard to generalize. > I meant to follow up on this issue on the freebsd-ports mailing > list, but I guess I never got around to mentioning it. As near as > I could tell, it is just a bad idea for a ports-makefile to depend > on setting CFLAGS. Many do, but most just hardcode the CFLAGS value they see in the configuration step in the (generated) ports Makefile. I run into this recently with mail/exim. Of course it was possible to work around this too, but it happened only when certain configuration options where given *and* CFLAGS was set in /etc/make.conf. There must be a better way to deal with this. -OliverReceived on Fri Aug 20 2004 - 10:08:38 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:07 UTC