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.
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.
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
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?
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.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
