On 2023/10/17 17:36, Klemens Nanni wrote:
> On Tue, Oct 17, 2023 at 04:32:19PM +0200, Theo Buehler wrote:
> > On Tue, Oct 17, 2023 at 03:27:26PM +0100, Stuart Henderson wrote:
> > > On 2023/10/16 21:07, Klemens Nanni wrote:
> > > > OK kn when that works on sparc64 for you and got wrapped in a
> > > > CHOSEN_COMPILER or MACHINE_ARCH check.
> > > 
> > > CHOSEN_COMPILER is messy because it has to go after the final
> > > .include <bsd.port.mk>
> > > 
> > > Using MACHINE_ARCH and enumerating the base-gcc archs is a
> > > terrible idea for this.
> > > 
> > > Could do !${PROPERTIES:Mclang} though my strong preference would
> > > be to avoid difference between flags on the different archs and
> > > always add to CXXFLAGS..
> > 
> > I would also have preferred that since I don't really see the reason
> > for treating gcc and clang differently, just because clang happens to
> > work for a reason that I did not investigate.
> > 
> > I used this (since I just used something similar for shared-mime-info)
> > and it does the expected:
> > 
> > EXTRA_ports-gcc +=  -I${LOCALBASE}/include
> > CXXFLAGS +=         ${EXTRA_${CHOSEN_COMPILER}}
> 
> No objection from me doing this unconditionally if this is too messy.
> 
> It just made it easier to reason about and, imho, also reads clearer than
> an unconditional include that implies configure/build script bugs when there
> are none (at least for clang archs).
> 

I don't see a configure script bug.

lz4 and lzo2 are picked up on ports-gcc archs at configure time.
>From the failed build log:

-- Looking for lzo1x_1_15_compress in lzo2
-- Looking for lzo1x_1_15_compress in lzo2 - not found
-- Looking for LZ4_compress_default in lz4
-- Looking for LZ4_compress_default in lz4 - found

IIRC ports-gcc's library search path includes /usr/local/lib which would
explain this. If that's not it, there's probably something deep in
/usr/local/share/cmake responsbile, but I no longer have the correct
glasses from the Infocom HHGTTG packaging to spend much time in
there.

These libraries aren't linked to the main snappy library but are used
in tests.

Adding the -I without doing anything else means that if lz4 or lzo2 are
present during configure and then junked, build will fail. (Probably
better if things like this are seen on base-clang archs too, rather
than failing very occasionally on a less common arch).

I think this is a better fix (checked there's no change to the produced
package so I didn't bump).

Index: Makefile
===================================================================
RCS file: /cvs/ports/archivers/snappy/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- Makefile    16 Oct 2023 21:17:52 -0000      1.20
+++ Makefile    17 Oct 2023 17:56:42 -0000
@@ -25,8 +25,12 @@ CONFIGURE_ARGS +=    -DBUILD_SHARED_LIBS=ON
                        -DINSTALL_GTEST=OFF \
                        -DSNAPPY_BUILD_BENCHMARKS=OFF
 
-EXTRA_ports-gcc +=     -I${LOCALBASE}/include
-CXXFLAGS +=            ${EXTRA_${CHOSEN_COMPILER}}
+# used in tests
+BUILD_DEPENDS =                archivers/lz4 \
+                       archivers/lzo2
+
+CXXFLAGS +=            -I${LOCALBASE}/include
+MODCMAKE_LDFLAGS =     -L${LOCALBASE}/lib
 
 # expects submodule/cannot use system library
 DIST_TUPLE =           github  google  googletest      
e40661d89b051e9ef4eb8a2420b74bf78b39ef41 \

Reply via email to