On Mon, 12 Nov 2018 01:40:02 -0700
"Anthony J. Bentley" <[email protected]> wrote:
> First, are paks architecture-independent? If so, they should be packaged
> separately from simutrans, with PKG_ARCH = *.
Thank you for looking at the port.
I will edit the port and mail it to this list.
Yes, paksets are architecture-independent. My port doesn't build
Pak64 from its source; it extracts an already-built Pak64.
> Second, can Pak64 and Pak128 be installed side-by-side, or are they
> mutually incompatible?
Yes, multiple paksets can be installed.
Pak64, Pak128, and Pak128.Britain seem to be the only recent paksets
with licenses that allow redistribution. Part of Pak128 has a weird
license. I would put for Pak128,
# Artistic 2.0 (doc/license.txt), CC-BY 3.0 (Percival_Maya_Temple),
# "These sounds are NOT available under terms of Artistic license 2.0,
# only distributed together with the pakset!" (sound/README.txt)
PERMIT_PACKAGE_CDROM = Yes
> If they're separately versioned, better to have a separate port with the
> correct version number, even if they're built from the same distfile.
makeobj shares some source files with simutrans but needs to recompile
them with -DMAKEOBJ, so a separate port of makeobj would not increase
the compile time.
> > do-build:
> > cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} \
> > sh -c 'unset CFLAGS && exec "$$0" "$$@"' \
> > gmake ${MAKE_FLAGS} ${ALL_TARGET}
>
> This should use ${MAKE_PROGRAM} instead of gmake. But can you find
> some way to avoid defining do-build by setting MAKE_FLAGS?
I know that `MAKE_FLAGS = CFLAGS=''` would fail because it would
cancel the `CFLAGS += ...` lines in WRKSRC/Makefile, but those lines
add important -D and -I flags. I will try to find if adding a
patch-Makefile is simpler than having this do-build target.
--
George Koehler <[email protected]>
