On Thu, Jul 04, 2013 at 11:14:04PM -0700, Ryan Freeman wrote:
> On Tue, Jun 11, 2013 at 04:02:11PM -0700, Ryan Freeman wrote:
> > Hi,
> >
> > Attached is a port of odamex, a doom engine specialising in making
> > multi-player games as easy as more modern fps, join/leave during games
> > etc. More than 4 players are also supported.
> >
> > There is a weekly game every Saturday night, exact times are usually
> > posted on odamex.net. The engine supports BOOM extensions and a couple
> > extra map editing features, so fancier levels can be played.
> >
> > It should respect the same data directories as the other doom engines,
> > so if you already have any iwads installed you're good to go.
>
> I have tried to split odamex into subpackages so that -server and -data
> can be installed without the client (for non-x11 servers)
>
> Howveer I am not sure if I have done this correctly, and it won't
> finish packaging due to an unknown install target.
>
> ninja: error: unknown target 'install'
>
> I read through /usr/ports/devel/cmake/cmake.port.mk and it seems
> to check if do-install is not set it will try and do what cmake
> sees fit, i.e. in the CMakeFiles.txt, which I thought I had set
> appropriately in the Makefile with manual do-install's.
>
> Upstream wants it to just build and be usable in a homedir which
> I didn't agree with so there is absolutely no install target in
> the distfile.
>
> Comments? Tips? :)
>
> -ryan
This is totally broken and wrong :)
you don't understand multi-packages, this stuff can't work.
with MULTI_PACKAGES, you build *everything* and package it separately.
The variables that can be indexed by subpackage are NOT all packages.
Refer to the "FLAVORS AND MULTI_PACKAGES" section of bsd.port.mk(5) for
the actual list ("the following variables are subpackage-dependent").
Note this does not include MODULES.
Your multiple do-build/do-install targets don't make any kind of sense.
(do you want to create pseudo-flavors that would disable the build
of some subpackages ? then you need to read about pseudo flavors in
bsd.port.mk(5), about bsd.port.arch.mk(5) and BUILD_PACKAGES, and to
look at actual examples, say, net/avahi... note that in that specific
case, the proper use of bsd.port.arch.mk(5) is vital to avoid errors
on arches that can't build the mono dependency).
We have dropped the :L in FLAVOR:L... about a year ago if memory serves ?
