I think you should add a variant that appears in a few of the other
GNU utils packages and that is to provide a +normal_install_names
variant which links the g* names to the non-g* names.
For example, here is coreutils:
configure.args --program-prefix=g \
--infodir=${prefix}/share/info \
--mandir=${prefix}/share/man \
--disable-nls
...
post-destroot {
if {[variant_isset normal_install_names]} {
system "cd ${destroot}${prefix}/bin && for f in g*;
do ln -s \$f `echo \$f | sed -e 's/^g//'`; done"
}
}
variant normal_install_names {
}
A number of other packages use this name naming convention.
Regards,
Blair
--
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<[EMAIL PROTECTED]>
Subversion training, consulting and support
http://www.orcaware.com/svn/
On Feb 24, 2007, at 10:07 PM, Elias Pipping wrote:
I don't know. Maybe those features aren't available in Panther.
Even if they are: call it freedom of choice.
Regards,
Elias Pipping
On Feb 25, 2007, at 7:01 AM, David MacMahon wrote:
On Feb 24, 2007, at 19:54 , Elias Pipping wrote:
assuming you already have the port, updated. compare the output of
/opt/local/bin/gfile /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/
libncurses.5.4.dylib
and
/usr/bin/file /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/
libncurses.5.4.dylib
that should answer your question.
If /usr/bin/file provides a functionality superset of gfile, why
would anyone install gfile?
If gfile has some useful features not found in /usr/bin/file, then
perhaps the ultimate solution is to enhance /opt/local/bin/file to
make it provide a functionality superset of /usr/bin/file.
Just my 2 cents' worth,
Dave
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
