On Nov 26, 2008, at 15:42, Big O wrote:
On Wed, Nov 26, 2008 at 12:52 AM, Ryan Schmidt wrote:
On Nov 25, 2008, at 13:35, Big O wrote:
On Mon, Nov 24, 2008 at 2:36 AM, Ryan Schmidt wrote:
Regarding all the kde4 ports you've committed...
You're fetching them all from the Subversion repository. Are
distfiles
not
available for any of them? If there are distfiles provided, they
should
be
used. If not, then you need to add svn as a build dependency. I
recommend
you declare it as "bin:svn:subversion", that way the Subversion
client
that
Apple provides in Leopard and later can be used on those systems
since it
should be sufficient, and for those using Tiger or earlier or
other OSes
without built-in Subversion clients the subversion port will be
built.
Ah yes, actually. distfiles are available. I just find it easier to
work from svn as I don't have to deal with the checksum section.
I'll
use those if you want though.
Yes, we do want you to use distfiles when available. Fetching from
svn is a
last resort.
Done.
What is the idea behind the line "pre-configure { file mkdir
${worksrcpath}
}"?
I forget. :-) I think it creates the build directory. kde
requires out
of source bids, so we use "build" as that directory. I'll check.
Ok, that sounds fine.
I mentioned this earlier regarding qimageblitz but I see now it
applies
to
all of them: /opt/local should not appear in the ports; the
variable
${prefix} should be used.
I'll change that. I forgot about those.
Ok great, thanks.
Fixed.
These ports use cmake, and I see several things you've had to do
in each
port to accommodate this. Should there be a cmake portgroup?
Since you're
gaining familiarity with what cmake needs as a result of these
ports,
maybe
you could work on such a portgroup.
Sure. What's a portgroup :-)
Read the guide:
http://guide.macports.org/#reference.portgroup
Will look into it after thanksgiving.
A portgroup encapsulates behavior that would otherwise need to be
repeated
in many ports. Most python 2.5 ports use the python25 portgroup.
Most ports
that compile using an xcode project use the xcode portgroup. Now
that we're
having lots of cmake-using ports, it might make sense to have a cmake
portgroup.
For the universal variant, is there a way to make use of
${configure.universal_archs} so that the user's selected
architectures
are
built, instead of assuming they want ppc and i386?
cmake universal setting separates architechtures with a semi-colon ( ;
) so this would requires a lot more work to get right.
It's not too difficult..... ${configure.universal_archs} is the space-
separated list of architectures, so the semicolon-separated list is
just [strsed ${configure.universal_archs} "g/ /;/"]
Well if they are selecting universal don't they want i386 and ppc? I
don't get it. Are you referring to x86_64 and ppc64 (does that even
exist) archs being options as well.
I don't know that cmake supports any options here besides ppc and
i386. I'll check though.
By default a universal build in MacPorts is i386 ppc. But as of
MacPorts
1.7.0, the user can select in the macports.conf which
architectures they
want. Maybe they want i386 ppc x86_64 ppc_64. Maybe they want just
i386
x86_64. The variable ${configure.universal_archs} contains the user's
selection, and ports should use it. (Actually, hopefully, ports
would never
need to look there and it would happen automatically, which it
hopefully
would if there were a cmake portgroup; it would handle this once
so all
cmake-using ports would benefit from it.)
CC me. not subscribed :-)
Please subscribe, so that you can post to the list and so that we
can have
conversations with you. If you're developing ports, and especially
if you're
a committer, you really need to be subscribed to and reading the
lists.
Subscribed.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
