Re: cad/oce

[Roland Illig <roland.illig%gmx.de@localhost>]

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