[Pan-users] Re: po/Makefile bug still there in 0.127 on MacOS X

[SciFi]

On Fri, 13 Apr 2007 07:21:55 -0400, David Shochat wrote:

> I tried building this on MacOS X with MacPorts. I still get the same
> problem as with 0.126 (and some earlier version) where in po/Makefile,
> we have macros GMSGFMT and MSGFMT defined to nothing on lines 47 and 48
> respectively, causing make to fail in po. As with those other versions,
> if I manually edit po/Makefile to define both macros to
> /opt/local/bin/msgfmt, all is well.
> This is MacOS X 10.4.9 Intel and MacPorts 1.400 recently upgraded to
> latest versions of pan's dependencies. No such problem on Ubuntu 6.10.
> -- David

Hi,

I took a quick look at MacPorts svn repo.  What they got labelled
there as pan2 is still the old pan-0.14.2.
<http://svn.macports.org/repository/macports/trunk/dports/news/>
They shouldn't call it pan2, just pan.  AIU the dependencies have
changed somewhat since then.

Can you try (or have you tried) to mimic the behaviour of how
MacPorts/Fink do things, such as add -I/opt/local/include manually
to your CxxFLAGS, and -L/opt/local/lib to your LDFLAGS, and
anything else needed?  Surely /opt/bin & /opt/local/bin are
already in your PATH, then I would hope 0.126's configure script
should already have detected where the msgfmt tools are located on
your system.  Stuff like this would be required since /opt isn't
usually considered a "normal" topdir to look under (whether it
should be is a matter for the projects to decide, for now the
package managers need to deal with it as they have been doing ;) ).

That being said, there are a few little-known tricks that perhaps
the pkg-mgrs should use.  You can set environment variables
(env-vars) to the actual locations of some programs, and most
configure/makefile scripts will use them.
For example in your case:
export MSGFMT=/opt/local/bin/msgfmt
...and you might also need:
export MSGMERGE=/opt/local/bin/msgmerge

There are a number of these that might need to be set.  These
sorts of things ought to be raised with the MacPorts folks, they
should be setting up a proper "build environment" for you when you
need to compile things by hand (not yet in the dports trees).


The rest of this is discussion -- while pkg-mgr eyeballs might be
reading this, please indulge me.  ;)

I wish MacPorts would do something similar to what Fink does: have
unstable and stable trees.  These three-decimal-digit versions of
pan2 are complete rewrites and ought to be considered unstable. 
This would leave alone the 'original' pan (0.14.2).

This is but only one reason why I don't use package managers; it's
so I can concentrate on the meat-&-potatoes of the original source
code themselves, submitting patches as needed to get things to
compile right out of the box.  ;)  Believe it or not, almost
everything for Gnome _can_ be built on Darwin/OSX right straight
from the tarballs -- pkg-mgrs _do_ make it easy to get the
dependencies done in the proper order etc. -- but I still don't
understand why they want to put things under /opt when /usr/local
was expressly designed to allow such testing to live there.

(Regular *ix systems use /usr/local ahead of /usr, both of which
can actually be separate mount-points; /usr/local shouldn't
contain any essential programs, and do not need to be mounted
[accessible] at boot-time, so it could live on e.g. firewire
drives or file- sharing systems like NFS etc.  What's more, Apple
don't install anything under /usr/local when installing OSX, so
this is already "prime real estate".  ;)  )


There are other reasons pkg-mgrs don't fit with regular software
development -- another big gripe with me is that they all rub-out
my CxxFLAGS that I want to use for tweaking for maximum gcc
optimisations when putting out a "gold master" release.


Well... I better stop there or I'll end up writing a novel.  ;)

Thanks for reading.  :)