February 2008 - macports-dev - lists.macosforge.org

Why compile Java ports and commons-logging
by Blair Zajac 05 Feb '08

05 Feb '08

Hi James, I've noticed that many of the Java ports you've worked on compile the Jar files newly. Is there any reason to do this? I like the fact that using the supplied jar files from a distribution are guaranteed to work. The reason I am asking is because with the upgrade to junit 4.4, commons-logging doesn't compile. compile.tests: [javac] Compiling 30 source files to /opt/local-development/var/macports/build/_opt_local-development_var_macports_sources_rsync.macports.org_release_ports_java_commons-logging/work/commons-logging-1.1-src/target/tests [javac] /opt/local-development/var/macports/build/_opt_local-development_var_macports_sources_rsync.macports.org_release_ports_java_commons-logging/work/commons-logging-1.1-src/src/test/org/apache/commons/logging/AbstractLogTest.java:20: package junit.framework does not exist [javac] import junit.framework.TestCase; Additionally, with the upgrade to Spring 2.5.x, one needs JDK 6 to compile it, so for that port, I had to disable compilation and just use the supplied jar's, which I'm happy to do. The only reason I see to compile a Java port is if you are patching the source code. Regards, Blair

2 3

Re: [33790] trunk/dports/devel/cut/Portfile
by Ryan Schmidt 05 Feb '08

05 Feb '08

On Feb 5, 2008, at 07:40, brett(a)macports.org wrote: > Revision: 33790 > http://trac.macosforge.org/projects/macports/changeset/33790 > Author: brett(a)macports.org > Date: 2008-02-05 05:40:09 -0800 (Tue, 05 Feb 2008) > > Log Message: > ----------- > linted > > Modified Paths: > -------------- > trunk/dports/devel/cut/Portfile > > Modified: trunk/dports/devel/cut/Portfile > =================================================================== > --- trunk/dports/devel/cut/Portfile 2008-02-05 13:28:15 UTC (rev > 33789) > +++ trunk/dports/devel/cut/Portfile 2008-02-05 13:40:09 UTC (rev > 33790) > @@ -1,12 +1,11 @@ > -# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: > nil; \ > -# c-basic-offset: 4 -*- > vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4 > # $Id$ [snip] Actually, we are trying to *add* modelines to portfiles, not remove them, though I wish we would standardize on a single modeline and not just whatever someone feels like using. "port lint" in MacPorts 1.6.0 is broken in its check for modelines. This was fixed in trunk already: http://trac.macosforge.org/projects/macports/ticket/13496

3 2

Problems compiling perl5.8 on 10.5
by Blair Zajac 05 Feb '08

05 Feb '08

Is anybody else having problems compiling perl5.8 on 10.5? I'm getting a bunch of warnings like this: make[1]: `lib/re.pm' is up to date. cd lib/unicore && DYLD_LIBRARY_PATH=/opt/local-development/var/macports/build/_opt_local-development_var_macports_sources_rsync.macports.org_release_ports_lang_perl5.8/work/perl-5.8.8 ../../miniperl -I../../lib mktables -w Can't locate File/Glob.pm in @INC (@INC contains: ../../lib /opt/local-development/lib/perl5/5.8.8/darwin-thread-multi-2level /opt/local-development/lib/perl5/5.8.8 /opt/local-development/lib/perl5/site_perl/5.8.8/darwin-thread-multi-2level /opt/local-development/lib/perl5/site_perl/5.8.8 /opt/local-development/lib/perl5/site_perl /opt/local-development/lib/perl5/vendor_perl/5.8.8/darwin-thread-multi-2level /opt/local-development/lib/perl5/vendor_perl/5.8.8 /opt/local-development/lib/perl5/vendor_perl .) at mktables line 2111. BEGIN failed--compilation aborted at mktables line 2111. To get around this, I did a custom patch by comparing 5.8.8 with the extraction using this command: $ tar xvfj perl-5.8.8.tar.bz2 $ rsync -Pavz rsync://public.activestate.com/perl-5.8.x/ 5.8.x/ $ cd 5.8.x $ diff -ruN ../5.8.8 . > ../patch.txt This generates a 3 Mbyte patch but it seems to work. Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair(a)orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/

2 3

Re: [33800] trunk/dports/devel/flex/Portfile
by Ryan Schmidt 05 Feb '08

05 Feb '08

On Feb 5, 2008, at 08:42, mww(a)macports.org wrote: > @@ -25,3 +26,6 @@ > test.run yes > test.target check > > +post-destroot { > + system "cd ${destroot}${prefix}/bin && ln -s flex flex++" > +} Why use system? Why not use the built-in ln command? post-destroot { ln -s flex ${destroot}${prefix}/bin/flex++ }

1 0

Re: [33797] trunk/dports/sysutils/beanstalkd/files/patch-Makefile.diff
by Ryan Schmidt 05 Feb '08

05 Feb '08

You added this as a new file. You should have used "svn cp" to copy it from patch-Makefile in r33533 so as to preserve the history and also to save space in the repository. On Feb 5, 2008, at 08:23, brett(a)macports.org wrote: > Revision: 33797 > http://trac.macosforge.org/projects/macports/changeset/33797 > Author: brett(a)macports.org > Date: 2008-02-05 06:22:21 -0800 (Tue, 05 Feb 2008) > > Log Message: > ----------- > update filename > > Added Paths: > ----------- > trunk/dports/sysutils/beanstalkd/files/patch-Makefile.diff > > Added: trunk/dports/sysutils/beanstalkd/files/patch-Makefile.diff > =================================================================== > --- trunk/dports/sysutils/beanstalkd/files/patch- > Makefile.diff (rev 0) > +++ trunk/dports/sysutils/beanstalkd/files/patch-Makefile.diff > 2008-02-05 14:22:21 UTC (rev 33797) > @@ -0,0 +1,21 @@ > +diff -u -r beanstalkd-0.6-orig/Makefile beanstalkd-0.6/Makefile > +--- beanstalkd-0.6-orig/Makefile 2008-01-02 21:16:41.000000000 -0500 > ++++ beanstalkd-0.6/Makefile 2008-01-18 10:48:25.000000000 -0500 > +@@ -1,12 +1,14 @@ > + program := beanstalkd > +-export CFLAGS := $(LDFLAGS) -Wall -Werror > +-export LDFLAGS := $(LDFLAGS) -levent > ++export CPPFLAGS := $(CPPFLAGS) -I__PREFIX__/include > ++export CFLAGS := $(CFLAGS) -Wall -Werror -I__PREFIX__/include > ++export LDFLAGS := $(LDFLAGS) -L__PREFIX__/lib -levent > + > + sources := $(shell ls *.c | fgrep -v $(program)) > + objects := $(sources:.c=.o) > + tests := $(sources:%=tests/test_%) > + > +-all: export CFLAGS := $(CFLAGS) -O2 > ++all: export CFLAGS := $(CFLAGS) -O2 -I__PREFIX__/include > ++all: export LDFLAGS := $(LDFLAGS) -L__PREFIX__/lib -levent > + all: $(program) > + > + debug: export CFLAGS := $(CFLAGS) -g -pg -DDEBUG

1 0

Variants handling: my $0.02.
by N_Ox 05 Feb '08

05 Feb '08

Hello there, One thing that is great about MacPorts is to be able to customise ports with variants. But there is two problems with them, I've thought about 2 new syntaxes to handle these problems. First, when a variant actually does something only when it is DISABLED, you would usually need to write: variant some_variant {} post-patch { if {![variant_isset some_variant]} { # Do something } } Why wouldn't we just write: variant -some_variant { post-patch { # Do something } } Now, what if we want to do something when the variant is enabled, and something else when it is disabled? Why won't we write that: variant some_variant { # Do something } else { # something else } Isn't that neat? These two sugar syntaxes would make the variant writing process cleaner. But maybe they could help us more... Let's say the variants which do something only when they are disabled (variant -some_variant) are always enabled by default. In this setup, `sudo port install some_port +another_variant` would install some_port @some_version+another_variant+some_variant. In the registry, we would save "some_variant another_variant" as the list of selected variants. Now, let's explicitely disable the variant: sudo port install some_port -some_variant +another_variant. In the registry, we would save "-some_variant another_variant". Then, on upgrade, we would just have to compare the name of the variant in the portfile (-some_variant) with each item of the list of selected variants to check whether or not we should enable it. No need to use default_variants. No more "Why the hell this variant is enabled when I upgrade this port?" whining. No more "no_x11" variant: variant -x11 { # no x11 } else { # x11 } But maybe all of this is just a "No more alive nerve cells in my brain." Regards, -- Anthony Ramine, the "Ports tree cleaning Maestro". <nox(a)macports.org>

5 9

Re: [33794] trunk/dports/shells/eash/Portfile
by Adam Mercer 05 Feb '08

05 Feb '08

On Feb 5, 2008 8:44 AM, <brett(a)macports.org> wrote: > Revision 33794 Author brett(a)macports.org Date 2008-02-05 05:42:44 -0800 > (Tue, 05 Feb 2008) > Log Message no longer available > > Removed Paths > > trunk/dports/shells/eash/Portfile Any reason why you haven't removed the trunk/dports/shells/eash directory as well? Cheers Adam

1 0

Re: [33768] trunk/dports/devel
by Ryan Schmidt 05 Feb '08

05 Feb '08

On Feb 4, 2008, at 15:41, brett(a)macports.org wrote: > +configure.pre_args --prefix=${prefix} \ > + --mandir=${prefix}/share/man Why not like this? configure.args --mandir=${prefix}/share/man

1 0

Re: [33768] trunk/dports/devel
by Rainer Müller 04 Feb '08

04 Feb '08

brett(a)macports.org wrote: > Revision: 33768 > http://trac.macosforge.org/projects/macports/changeset/33768 > Author: brett(a)macports.org > Date: 2008-02-04 13:40:14 -0800 (Mon, 04 Feb 2008) > > Log Message: > ----------- > initial libmemcached port > > Added Paths: > ----------- > trunk/dports/devel/libmemcached/ > trunk/dports/devel/libmemcached/Portfile > > Added: trunk/dports/devel/libmemcached/Portfile > =================================================================== > --- trunk/dports/devel/libmemcached/Portfile (rev 0) > +++ trunk/dports/devel/libmemcached/Portfile 2008-02-04 21:40:14 UTC (rev 33768) > @@ -0,0 +1,17 @@ > +# $Id$ > + > +PortSystem 1.0 > +name libmemcached > +version 0.15 > +description libmemcached is a C and C++ client library to the memcached server > +long_description libmemcached is a C and C++ client library for memcached. \ > + It has been designed to be light on memory usage, thread safe, \ > + and provide full access to server side methods. > +maintainers brett(a)macports.org > +categories devel > +platforms darwin > +homepage http://tangent.org/552/libmemcached.html > +master_sites http://download.tangent.org/ > +checksums sha1 b54a0cf6551627541d258d83f14228337e379bab > +configure.pre_args --prefix=${prefix} \ > + --mandir=${prefix}/share/man Please run `port lint' on newly added ports before committing them. This port does not match our current guidelines. ---> Verifying Portfile for libmemcached Warning: Line 4 should be a newline (after PortSystem) Warning: Line 12 has trailing whitespace before newline Warning: Line 17 has trailing whitespace before newline ---> 0 errors and 3 warnings found. Additionally, is there a difference to the already existing libmemcache port? Is that superseeded by libmemcached? Rainer

1 0

Re: [33724] trunk/base/src
by Ryan Schmidt 04 Feb '08

04 Feb '08

On Feb 4, 2008, at 02:29, afb(a)macports.org wrote: > Modified: trunk/base/src/port1.0/portconfigure.tcl > =================================================================== > --- trunk/base/src/port1.0/portconfigure.tcl 2008-02-04 03:30:08 > UTC (rev 33723) > +++ trunk/base/src/port1.0/portconfigure.tcl 2008-02-04 08:29:16 > UTC (rev 33724) > @@ -102,14 +102,9 @@ > default configure.pkg_config {} > default configure.pkg_config_path {} > > -# Universal options & default values. > -set target "10.4" > -set sysroot "/Developer/SDKs/MacOSX10.4u.sdk" > -set universal_archs {ppc i386} > - > options configure.universal_target configure.universal_sysroot > configure.universal_archs configure.universal_args > configure.universal_cflags configure.universal_cppflags > configure.universal_cxxflags configure.universal_ldflags > -default configure.universal_target {${target}} > -default configure.universal_sysroot {${sysroot}} > +default configure.universal_target {${universal_target}} > +default configure.universal_sysroot {${universal_sysroot}} > default configure.universal_archs {${universal_archs}} > default configure.universal_args > {[configure_get_universal_args]} > default configure.universal_cflags > {[configure_get_universal_cflags]} This breaks those ports that use ${sysroot}. Currently that's cairo, libiconv and xrender. $ sudo port install cairo +universal Error: Unable to execute port: can't read "sysroot": no such variable $ Maybe ${sysroot} should be retained until ${universal_sysroot} is in a released version of MacPorts and these ports are updated to use it?

2 1