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. :) _______________________________________________ Pan-users mailing list [EMAIL PROTECTED] http://lists.nongnu.org/mailman/listinfo/pan-users
