[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-tech-pkg
Subject:    Re: cad/oce
From:       Roland Illig <roland.illig () gmx ! de>
Date:       2022-03-12 9:12:28
Message-ID: edc19995-912a-dcdd-21f6-99a927ad4de4 () gmx ! de
[Download RAW message or body]

Am 12.03.2022 um 01:22 schrieb Brook Milligan:
> I am working to get cad/oce compiling on Darwin, which it now does after some work \
> (see all the patches below).  One change in the Makefile is the following, which \
> only changes the suffix of the files to fix up. 
> +.if !empty(OPSYS:MDarwin)

The more idiomatic form is:

.if ${OPSYS} == "Darwin"

The variable OPSYS is a single-word variable, therefore the pattern
matching using ':M' is overkill.

The '!empty', while common, is harder to read due to the '!' that means
a negation.  But this negation really checks for the positive case that
the word "Darwin" _is_ in the list, so it's a confusing negation.

If the variable OPSYS is not defined at this point, bmake should error
out.  It wouldn't do this in the '!empty' form, but the direct '.if
${OPSYS}' requires the variable to be defined.

> +SUBST_SED.prefix=	-e "s|${BUILDLINK_DIR}/lib/lib\([0-9a-zA-Z_-]*\)\.dylib|\1|g"
> +.else
> SUBST_SED.prefix=	-e "s|${BUILDLINK_DIR}/lib/lib\([0-9a-zA-Z_-]*\)\.so|\1|g"
> +.endif
> 
> It seems that there should be some make variable for the platform-specific suffix \
> (i.e., .so versus .dylib), but I cannot find what it is.

$ bmake help topic=dylib | cat
No help found for dylib, but it appears in:

../../lang/ruby/rubyversion.mk
../../mk/check/check-shlibs.mk
../../mk/pgsql.buildlink3.mk
../../mk/pkgformat/pkg/metadata.mk
../../mk/platform/Darwin.mk
../../mk/plist/plist.mk

mk/platform/Darwin.mk defines _OPSYS_SHLIB_TYPE=dylib, and this variable
is used in SHLIB_TYPE, which is part of the public API.  But on ELF
platforms, its value is "ELF", not "so".

Even the brute-force approach "grep -wr dylib ../../mk" doesn't reveal
anything useful.  The file mk/pgsql.buildlink3.mk does its own thing to
solve the same problem.  So I guess your current approach is fine.

> Please advise on this and any other aspect of the attached patch.

I first thought that instead of defining the variables PLIST.Darwin and
PLIST.not_Darwin, you could list these files in separate PLIST files.
"bmake help topic=plist" shows that the file PLIST.Darwin would already
be handled, but there is no existing magic for PLIST.not_Darwin, which
makes your current approach the best available.

Looks good to me.

Roland


[prev in list] [next in list] [prev in thread] [next in thread]