svn commit: r318993 - in head: archivers/libcabinet archivers/libcabinet/files devel/libpdel devel/libxalloc finance/libstocks games/libshhcards games/libshhcards/files japanese/ming math/linpack w...

[Baptiste Daroussin]

On Sat, May 25, 2013 at 02:48:02AM +0000, Alexey Dokuchaev wrote:
> On Fri, May 24, 2013 at 04:35:31PM +0000, Baptiste Daroussin wrote:
> > New Revision: 318993
> > URL: http://svnweb.freebsd.org/changeset/ports/318993
> > 
> > Log:
> >   Do not let system make.conf inpact the port's makefile
> >   This fixes build on current
> > 
> > @@ -13,6 +13,7 @@ USE_LDCONFIG=	yes
> >  
> >  SRCFILE=	${WRKSRC}/listcab.cpp
> >  PROGFILE=	${SRCFILE:S/.cpp$//}
> > +MAKE_ENV=	WITHOUT_PROFILE=yes __MAKE_CONF=/dev/null SRCCONF=/dev/null
> 
> This looks bogus.  Can you shed some light on what exactly breaks these
> ports?  Can they be fixed without introducing cryptic constructs in their
> ports Makefiles?  I'd volunteer to fix (when -current gets stable enough
> to be feasible for remote upgrade; I don't want to get unbootable box).
> 
> ./danfe

I know this looks bogus, but imho this isn't the port should have control on own
and what things are being built and installed, not a third party file.

in that case what is fixed is that if a user set WITH_PROFILE in src.conf a lib
will end up creating and installing a _p.a file, we have the same for .symbols,
and probably more things.

btw: no need to be in current to experience those plist breakage

we can still offer the user the same kind of control pn the build process, but
we should to it via the port itself.

regards,
Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-ports-head/attachments/20130525/d8bc367a/attachment.sig>