CMake support for DragonFly BSD

Joerg Sonnenberger joerg at britannica.bec.de
Fri Jul 13 11:03:51 PDT 2007


On Fri, Jul 13, 2007 at 01:34:10PM -0400, Alexander Neundorf wrote:
> On Friday 13 July 2007 13:22, Joerg Sonnenberger wrote:
> > On Fri, Jul 13, 2007 at 12:53:49PM -0400, Alexander Neundorf wrote:
> > > > The prefix is fully user-settable and the patch ensures
> > > > that cmake works with dependencies installed via pkgsrc.
> > >
> > > Can you please explain, I know basically nothing about pkgsrc.
> >
> > What I mean is: when I build cmake to install to /some/arbitrary/path
> > via pkgsrc, I expect it to look for normal libraries in the same
> 
> So would it help if cmake also checks the bin/, lib/ and include/ directories 
> of its own install location ?
> This would be easy to add.

Yes, that is basically what the patch tries when adding @PREFIX@/...
This is IMO preferable to hard-coding any non-standard locations (/usr),
/usr/local makes a lot less sense with this. If I don't install into
/usr/local, I normally wouldn't want software to scan it either.

> > location. I would also prefer to keep the list of hard-coded directories
> > down, but that conflicts with the idea of "work-out-of-the-box on
> > insane platforms". For X11, pkgsrc knows where to look or which one to
> > pick up. That can make a difference when you have both native headers
> > and modular Xorg installed (think SunOS and other older Unix versions).
> 
> There are still the environment variables which can be set up. What do you 
> think about this ?

The environmental variables are not set by the normal user, I think.
When cmake is built by pkgsrc, the system knows what location it should
look for.

A good compromise would a package-system switch be that removes most
additional path names and add a few options to specify where to look for
header files and libraries. The X11 stuff as second option is logical as
well.

Joerg





More information about the Users mailing list