On Thu, 18 Mar 2010 08:14:47 -0400 Mark Bucciarelli <mkb...@gmail.com>
wrote:
> On Thu, Mar 18, 2010 at 1:20 AM, J.C. Roberts
> <list-...@designtools.org> wrote:
> >
> > The size is not that bad by comparison and dealing with a single
> > file is more reliable dealing with a whole bunch of small files,
> >
>
> I tried building from the large archive, but the directory tree
> after make expand didn't match what the ports makefile
> expected. Manually, I would type something like this:
>
> $ cd /usr/ports/obj/MonetDB*/MonetDB*/MonetDB/MonetDB/
I'm going to make a suggestion; do your porting on -current! ;)
The old /usr/ports/obj/ is a dead give away of you running 4.6.
The new 4.7 uses /usr/ports/pobj/ due to conflicts (I think it was
something to do with bulk builds). More importantly, there have been
*tons* of changes made to ports/packages since 4.6.
> $ ./configure
> $ gmake
> $ gmake install
> $ cd ../../
> $ cd clients/clients
> $ ./configure
> etc.
>
> I got as far as adding a do-build target that wasn't
> triggered. (Maybe I used the wrong hook name?)
> Anyway, it was getting complex.
>
> Upstream also provides a huge shell script in the
> big archive but I never build that way myself and it
> has lots and lots of logic in it I'll never use.
>
If you were successful in getting it running with your "manual" process
above, making a nice port of MonetDB should be fairly straight forward.
I have it downloading at the moment, but won't be able to look at it
again until later this weekend.
I don't know a darn thing about MonetDB, so I'm half expecting a bunch
of watter lilies.
It would be great if you drop-kicked me towards the *exact* build and
install process you've been using manually, and any other relevant
information for setup/testing.
It's getting "complex" because you're avoiding *their* "normal" way of
doing it with their big build script.
If the script is well written, you can often get away with setting:
CONFIGURE_SCRIPT =
Of course, a "well written" build script is a *LOT* to ask for and
seldom delivered. ;)
Actually, going the "complex" route is to your advantage in the case of
a big database since it allows you to do MULTI_PACKAGES much more
cleanly. Unfortunately, our standard Makefile template for new ports
ports/infrastructure/templates/Makefile.template
does not contain info for handling MULTI_PACKAGES but it is a nice
starting point. You'll probably want to check out the Makefile for
databases/mysql (YAY Brad! --he does great work) and some of the other
ports using MULTI_PACKAGES.
> Using tiny and simple Makefiles seems cleaner
> and easier to maintian.
>
Yep.
> >
> > if upstream has a habit of changing/re-releasing files under the
> > same file name (e.g. screws up chksum and forces the project to
> > mirror the "old" version after release).
> >
>
> I spot checked a few releases and they seem
> good about versioning.
>
It's not something you can (easily) spot check. It's when upstream
changes the *content* of a file while retaining the same file name.
This makes a big mess.
