James Gregurich | 1 Mar 03:57 2011
Picon

Re: submitting support for suppressing static and dynamic libs


In this latest round of work, I've added support for suppressing static and dynamic libs. This feature is useful because when passing -l flags to the linker, dynamic libs take precedence over static libs. If one wants to use static libs, then he has to explicitly reference the lib by path using the -L option. The problem is avoided by not having dynamic libs if you don't need them. Also, Apple disallows use of dylibs for iOS anyway.  I've added two more variables to the .conf file: 

$suppress_static_libs
$suppress_shared_libs


If the first is on, dylib generation is forced and static lib generation is suppressed.
If the second is on, static generation is forced and dylib generation is suppressed.
If neither flag is set, the system defaults to the usual behavior.
If both flags are set, the system aborts with an error indicating the state is invalid.

The changes for this feature are in portconfigure.tcl and macports.tcl. 


For autoconf ports, no changes should be necessary to the portfile to support these features. The normal configure flags are used to enable and disable the building of the libs.  For custom build systems, the port files will have to be modified to check the variables. However, if the flags are not used in the .conf file, then all existing portfiles will work normally. 

Portmain.tcl has a minor bugfix.


These changes have been tested with the 5 test ports that have been used and  against MacOSX, iOS 4.2 and the iOS simulator for 4.2. Everything works as expected as best I can tell. I'm not planning any more changes until I hear back from the macports developers as to whether this work is desired. I have what I need to proceed on my iOS projects for now with this latest round of changes. I think I've demoed that macports can be cleanly modified to fully support building libs for iOS. So, my job is done and I'm returning to my normal duties.

There does need to be further thought put into the design of the system. In some of the ports, I had to use conditional code to determine whether a build is using muniversal or not. This code is necessary because variables like worksrcpath are not adjusted for muniversal. So, if it is a universal build, I have to use one variable and it if isnt, I have to use another. Some thought needs to be put into a new variable arrangment so that for muniversal builds, a port can refer to either worksrcpath or the muniversal equivalent of worksrcpath for the current architecture with a single variable. Other variables that need to be considered in the same way:  destroot, configure.cc_archflags and its cousins.

isysroot needs to be worked into the design a little more thoroughly so that portfiles don't have to hard-code isysroot. Perhaps it can be tacked on to archflags when necessary.


muniversal needs to be extended so that each architecture gets its own set of pre/post phases. The variables need to be set up so that a single set of variables can serve both the universal and non-universal cases....as discussed earlier. Perhaps the answer is to create a new portgroup or new version of muniversal that changes this behavior to preserve compatibility with existing portfiles. portfiles that get upgraded to work with iOS can be changed to use the new version of muniversal. I wasn't sure how to set up the pre/post phases, so I just set up simple call-back functions as earlier documented. 


my latest changes can be downloaded at the following link. The download is 200MB because I didn't bother going to the extra trouble to strip out the binaries. I was in a hurry, and didn't want to take the time. The download only takes 5 or 10 minutes on a decent connection. This should be good enough.





-James

On Feb 16, 2011, at 7:33 PM, James Gregurich wrote:


I have added additional functionality to macports. The following ports now build:  icu, zlib, bzip2, expat and boost. These ports build universal and non-universal for MacOSX (ppc, ppc64, i386, x86_64) and iPhoneOS (armv6, armv7) as well as non-universal for the iPhoneSimulator (only i386 exists on this one). They build with the default compilers for each platform as well as clang 2.8 for MacOSX.


I think this experiment is successful. I've made only minor adjustments to the design on macports. Most of the work is simply logically existing the design that is already present to handle additional functionality needed for complicated projects (such as boost). The changes to ports files are reasonable. Boost required significant alteration due to the nature of the boost build system and the desire to use "combined" architecture when possible to speed up builds. Ports for MacOSX should keep building without modification. Ports can be updated to handle iOS on an as-needed basis. The change can be as simple as adding the muniversal PortGroup if autoconf is used as the build system for the projects as configure scripts break on multiple architecture flags on the preprocessor check. 

I have tested the changes against clang and while using the 10.5 sdk. The 5 ports I've handled are certainly diverse. I can't imagine any project having more complicated needs than boost. 

There is certainly a need in the mac developer community to provide for iOS development, and I have proven that macports can be cleanly extended to handle the job.  Given my results, I am requesting macports accept the work. I'm sure additional changes will be required to make the work complete, and I'm certainly willing to cooperate on providing the developer resources to get the work done. 



link to zip file of /iopt:   



The following files have been changed:

macports.conf
portmain.tcl
portconfigure.tcl
portutil.tcl
muniversal.tcl
xcodeversion.tcl

portfiles for the projects listed above.


The following functionality has been implemented:

1) I have extended the muniversal portgroup to add pre- and post- callbacks on configure, destroot and build such that a portfile can be called for configuring, building and destrooting each architecture being built. These callbacks are simple flat functions. There is probably a way more consistent with the overall design to handle these callbacks, but no one answered my request for guidance on the point, so I just set it up the best way I could figure out on my own. Certainly, the design is good enough to prove the concept works.


2) corrected flaw in the setting of the configure CPPFLAGS such that the preprocessor gets the correct sdk and arch flags.

3) hard-coded support for clang 2.x. see 'macports-clang-2.0' in the code. added entries for apple's clang with cxx and cpp. 

4) added parallel build functionality back to boost portfile

5) added the following variables:

muniversal-destroot
   configure.cxx_archflags
   configure.target_uses_host_option  (overrides adding --host to configure.cmd invocation)


6) added the following callbacks:


   pre-muniversal-configure  
   post-muniversal-configure
   post-muniversal-destroot
   pre-muniversal-build
   post-muniversal-build


7) I broke the assumption that xcode must in $developer_dir since it isn't there in the case of an iOS cross-compile.




changes to boost portfile:

1) the boost build system offers a "combined" architecture setting for building universal binaries on MacOSX. If the desired configuration can be handled by the combined architecture mechanism, then use it. If it can't, then fall back to using muniversal portgroup to build universal binaries. 

2) program_options does not build on iOS due to sdk header differences. There is a patch coming in a future version of boost. program_options is disabled.

3) only static libs are generated for iOS.

NOTE: I have not tested the variants.


changes to icu portfile:

1) minor modifications and cleanup.


changes to zlib portfile:

1) added muniversal portgroup.


changes to bzip2 portfile:

1) added sdk flags to build args.
2) patch makefile in post-destroot to disable tests for a cross-compile. 


changes to expat portfile:

1) added muniversal portgroup.























_______________________________________________
macports-dev mailing list
macports-dev-qhrM8SXbD5JBG2y7cWolcg@public.gmane.orgforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

<div>
<div><br></div>
<div>In this latest round of work, I've added&nbsp;support for suppressing static and dynamic libs. This feature is useful because when passing -l flags to the linker, dynamic libs take precedence over static libs. If one wants to use static libs, then he has to explicitly reference the lib by path using the -L option. The problem is avoided by not having dynamic libs if you don't need them. Also, Apple disallows use of dylibs for iOS anyway. &nbsp;I've added two more variables to the .conf file:&nbsp;</div>
<div><br></div>
<div>
<div>$suppress_static_libs</div>
<div>$suppress_shared_libs</div>
</div>
<div><br></div>
<div><br></div>
<div>If the first is on, dylib generation is forced and static lib generation is suppressed.</div>
<div>If the second is on, static generation is forced and dylib generation is suppressed.</div>
<div>If neither flag is set, the system defaults to the usual behavior.</div>
<div>If both flags are set, the system aborts with an error indicating the state is invalid.</div>
<div><br></div>
<div>The changes for this feature are in portconfigure.tcl and macports.tcl.&nbsp;</div>
<div><br></div>
<div><br></div>
<div>For autoconf ports, no changes should be necessary to the portfile to support these features. The normal configure flags are used to enable and disable the building of the libs. &nbsp;For custom build systems, the port files will have to be modified to check the variables. However, if the flags are not used in the .conf file, then all existing portfiles will work normally.&nbsp;</div>
<div><br></div>
<div>Portmain.tcl has a minor bugfix.</div>
<div><br></div>
<div><br></div>
<div>These changes have been tested with the 5 test ports that have been used and &nbsp;against MacOSX, iOS 4.2 and the iOS simulator for 4.2. Everything works as expected as best I can tell. I'm not planning any more changes until I hear back from the macports developers as to whether this work is desired. I have what I need to proceed on my iOS projects for now with this latest round of changes. I think I've demoed that macports can be cleanly modified to fully support building libs for iOS. So, my job is done and I'm returning to my normal duties.</div>
<div><br></div>
<div>There does need to be further thought put into the design of the system. In some of the ports, I had to use conditional code to determine whether a build is using muniversal or not. This code is necessary because variables like worksrcpath are not adjusted for muniversal. So, if it is a universal build, I have to use one variable and it if isnt, I have to use another. Some thought needs to be put into a new variable arrangment so that for muniversal builds, a port can refer to either worksrcpath or the muniversal equivalent of worksrcpath for the current architecture with a single variable. Other variables that need to be considered in the same way: &nbsp;destroot,&nbsp;configure.cc_archflags and its cousins.</div>
<div><br></div>
<div>isysroot needs to be worked into the design a little more thoroughly so that portfiles don't have to hard-code isysroot. Perhaps it can be tacked on to archflags when necessary.</div>
<div><br></div>
<div><br></div>
<div>muniversal needs to be extended so that each architecture gets its own set of pre/post phases. The variables need to be set up so that a single set of variables can serve both the universal and non-universal cases....as discussed earlier. Perhaps the answer is to create a new portgroup or new version of muniversal that changes this behavior to preserve compatibility with existing portfiles. portfiles that get upgraded to work with iOS can be changed to use the new version of muniversal. I wasn't sure how to set up the pre/post phases, so I just set up simple call-back functions as earlier documented.&nbsp;</div>
<div><br></div>
<div><br></div>
<div>my latest changes can be downloaded at the following link. The download is 200MB because I didn't bother going to the extra trouble to strip out the binaries. I was in a hurry, and didn't want to take the time. The download only takes 5 or 10 minutes on a decent connection. This should be good enough.</div>
<div><br></div>
<div><span class="Apple-style-span"><a href="https://files.me.com/bayoubengal/9i3y2z">https://files.me.com/bayoubengal/9i3y2z</a></span></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div>-James</div>
<br><div>
<div>On Feb 16, 2011, at 7:33 PM, James Gregurich wrote:</div>
<br class="Apple-interchange-newline"><blockquote type="cite">
<div>
<div><br></div>
<div>I have added additional functionality to macports. The following ports now build: &nbsp;icu, zlib, bzip2, expat and boost. These ports build universal and non-universal for MacOSX (ppc, ppc64, i386, x86_64) and iPhoneOS (armv6, armv7) as well as non-universal for the iPhoneSimulator (only i386 exists on this one). They build with the default compilers for each platform as well as clang 2.8 for MacOSX.</div>
<div><br></div>
<div><br></div>
<div>I think this experiment is successful. I've made only minor adjustments to the design on macports. Most of the work is simply logically existing the design that is already present to handle additional functionality needed for complicated projects (such as boost). The changes to ports files are reasonable. Boost required significant alteration due to the nature of the boost build system and the desire to use "combined" architecture when possible to speed up builds. Ports for MacOSX should keep building without modification. Ports can be updated to handle iOS on an as-needed basis. The change can be as simple as adding the muniversal PortGroup if autoconf is used as the build system for the projects as configure scripts break on multiple architecture flags on the preprocessor check.&nbsp;</div>
<div><br></div>
<div>I have tested the changes against clang and while using the 10.5 sdk. The 5 ports I've handled are certainly diverse. I can't imagine any project having more complicated needs than boost.&nbsp;</div>
<div><br></div>
<div>There is certainly a need in the mac developer community to provide for iOS development, and I have proven that macports can be cleanly extended to handle the job. &nbsp;Given my results, I am requesting macports accept the work. I'm sure additional changes will be required to make the work complete, and I'm certainly willing to cooperate on providing the developer resources to get the work done.&nbsp;</div>
<div><br></div>
<div><br></div>
<div><br></div>
<div>link to zip file of /iopt: &nbsp;&nbsp;<span class="Apple-style-span"></span>
</div>
<div><br></div>
<div><br></div>
<div><br></div>
<div>The following files have been changed:</div>
<div><br></div>
<div>macports.conf</div>
<div>portmain.tcl</div>
<div>portconfigure.tcl</div>
<div>portutil.tcl</div>
<div>muniversal.tcl</div>
<div>xcodeversion.tcl</div>
<div><br></div>
<div>portfiles for the projects listed above.</div>
<div><br></div>
<div><br></div>
<div>The following functionality has been implemented:</div>
<div><br></div>
<div>1) I have extended the muniversal portgroup to add pre- and post- callbacks on configure, destroot and build such that a portfile can be called for configuring, building and destrooting each architecture being built. These callbacks are simple flat functions. There is probably a way more consistent with the overall design to handle these callbacks, but no one answered my request for guidance on the point, so I just set it up the best way I could figure out on my own. Certainly, the design is good enough to prove the concept works.</div>
<div><br></div>
<div><br></div>
<div>2) corrected flaw in the setting of the configure CPPFLAGS such that the preprocessor gets the correct sdk and arch flags.</div>
<div><br></div>
<div>3) hard-coded support for clang 2.x. see '<span class="Apple-style-span">macports-clang-2.0</span>' in the code. added entries for apple's clang with cxx and cpp.&nbsp;</div>
<div><br></div>
<div>4) added parallel build functionality back to boost portfile</div>
<div><br></div>
<div>5) added the following variables:</div>
<div><br></div>
<div><span class="Apple-style-span"><span class="Apple-tab-span"><span class="Apple-style-span">	</span></span>muniversal-destroot</span></div>
<div>
<span class="Apple-style-span"></span><span class="Apple-style-span">&nbsp;&nbsp; configure.cxx_archflags</span>
</div>
<div>
<span class="Apple-style-span">&nbsp;&nbsp;&nbsp;</span><span class="Apple-style-span">configure.target_uses_host_option &nbsp;(overrides adding --host to configure.cmd invocation)</span>
</div>
<div><span class="Apple-tab-span"><br></span></div>
<div><span class="Apple-tab-span"><br></span></div>
<div>
<span class="Apple-tab-span">6</span>) added the following callbacks:</div>
<div><br></div>
<div><br></div>
<div>
<div>&nbsp;&nbsp; pre-muniversal-configure &nbsp;</div>
<div>&nbsp;&nbsp; post-muniversal-configure</div>
<div>&nbsp;&nbsp; post-muniversal-destroot</div>
<div>&nbsp;&nbsp; pre-muniversal-build</div>
<div>&nbsp;&nbsp; post-muniversal-build</div>
</div>
<div><br></div>
<div><br></div>
<div>7) I broke the assumption that xcode must in $developer_dir since it isn't there in the case of an iOS cross-compile.</div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div>changes to boost portfile:</div>
<div><br></div>
<div><div>1) the boost build system offers a "combined" architecture setting for building universal binaries on MacOSX. If the desired configuration can be handled by the combined architecture mechanism, then use it. If it can't, then fall back to using muniversal portgroup to build universal binaries.&nbsp;</div></div>
<div><br></div>
<div>2) program_options does not build on iOS due to sdk header differences. There is a patch coming in a future version of boost. program_options is disabled.</div>
<div><br></div>
<div>3) only static libs are generated for iOS.</div>
<div><br></div>
<div>
<span class="Apple-tab-span">N</span>OTE: I have not tested the variants.</div>
<div><br></div>
<div><br></div>
<div>changes to icu portfile:</div>
<div><br></div>
<div>1) minor modifications and cleanup.</div>
<div><br></div>
<div><br></div>
<div>changes to zlib portfile:</div>
<div><br></div>
<div>1) added muniversal portgroup.</div>
<div><br></div>
<div><br></div>
<div>changes to bzip2 portfile:</div>
<div><br></div>
<div>1) added sdk flags to build args.</div>
<div>2) patch makefile in post-destroot to disable tests for a cross-compile.&nbsp;</div>
<div><br></div>
<div><br></div>
<div>changes to expat portfile:</div>
<div><br></div>
<div>1) added muniversal portgroup.</div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><span class="Apple-tab-span"><br></span></div>
<div><span class="Apple-tab-span"><br></span></div>
<div><span class="Apple-tab-span"><br></span></div>
<div><span class="Apple-tab-span"><br></span></div>
<div><span class="Apple-tab-span"><br></span></div>
<div><span class="Apple-tab-span"><br></span></div>
<div><span class="Apple-tab-span"><br></span></div>
<div><span class="Apple-tab-span"><br></span></div>
<div><span class="Apple-tab-span"><br></span></div>
<div><span class="Apple-tab-span"><br></span></div>
<div><span class="Apple-tab-span"><br></span></div>
<div><span class="Apple-tab-span"><br></span></div>
<div><span class="Apple-tab-span"><br></span></div>
</div>_______________________________________________<br>macports-dev mailing list<br><a href="mailto:macports-dev@...">macports-dev@...forge.org</a><br>http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev<br>
</blockquote>
</div>
<br>
</div>
Rainer Müller | 1 Mar 17:25 2011

Re: perl5, perl5.* changes

On 2011-03-01 16:45 , Dan Ports wrote:
> On Mon, Feb 28, 2011 at 04:34:22PM -0800, Dan Ports wrote:
>> I see this as a high-priority issue that affects many people. So if we
>> can get things closer to working by revbumping a bunch of ports, we
>> should do that ASAP. Is there any reason *not* to revbump p5-* (or more
>> precisely anything using PortGroup perl5?)
> 
> If no one objects, I'll do exactly this today.

Not an objection per se, but as this has been discussed on
macports-users only, I am explicitly adding Eric and Marcus as current
maintainers of perl5 to CC to this post.

Rainer
Dan Ports | 1 Mar 19:44 2011

Re: perl5, perl5.* changes

On Tue, Mar 01, 2011 at 05:25:12PM +0100, Rainer M?ller wrote:
> Not an objection per se, but as this has been discussed on
> macports-users only, I am explicitly adding Eric and Marcus as current
> maintainers of perl5 to CC to this post.

Thanks -- I missed that this was going only to macports-users
and not -dev. Sorry about that.

On Tue, Mar 01, 2011 at 11:09:19AM -0500, Arno Hautala wrote:
> One, slight, objection.
> 
> In the interest of not having to revbump twice, are we ready to fully
> migrate to 5.12?
> I've seen several votes for dropping the multiple perl versions and
> just following the latest stable release. I haven't seen any requests
> to stick with the existing multiple version "support".

I'm not adverse to waiting if indeed a solution to the
multiple-versions issue is imminent. (I don't want to revbump 800+
ports any more than I want to force everyone to rebuild all of them
twice.)

But if there isn't a consensus on what to do about that, or how to
implement the solution -- and Eric's email suggests that's the case --
then getting it right may take some time. If that's the case, I'd
prefer to err on the side of revbumping early (and perhaps needing to
do so again later) so people are not left with a broken perl in the
meantime.

Dan

--

-- 
Dan R. K. Ports              MIT CSAIL                http://drkp.net/
Ryan Schmidt | 1 Mar 20:17 2011

Re: [76594] trunk/dports/tex

On Mar 1, 2011, at 12:20, phw@... wrote:

> Revision: 76594
>          http://trac.macports.org/changeset/76594
> Author:   phw@...
> Date:     2011-03-01 10:20:03 -0800 (Tue, 01 Mar 2011)
> Log Message:
> -----------
> New port: tex-whizzytex

> +pre-configure {
> +                  system "open /Applications/Utilities/X11.app"
> +}

This doesn't seem like a good idea. What if the user uses MacPorts X11 in ${applications_dir}/X11.app
instead of Apple's?

It also doesn't seem necessary because Leopard and later automatically open X11 for you when needed, via
launchd magic.

For Tiger, there's "open-x11", but I'm not sure if it would know to handle MacPorts X11 (but that might be ok
since Tiger is becoming not so relevant).

http://newsgroups.derkeiler.com/Archive/Comp/comp.sys.mac.system/2007-10/msg02716.html

> +post-activate   {
> +
> +                        system "mktexlsr"
> +			ui_msg "To use this, put the following into your ~/.emacs:"
> +			ui_msg "(add-to-list 'load-path \"${prefix}/share/whizzytex/emacs/\")"
> +			ui_msg "(autoload 'whizzytex-mode"
> +			ui_msg "\"whizzytex\""
> +			ui_msg "\"WhizzyTeX, a minor-mode WYSIWIG environment for LaTeX\" t)"
> + 			}

You should use the notes command here, instead of ui_msgs.

Daniel J. Luke | 1 Mar 21:13 2011
Picon

Re: perl5, perl5.* changes

On Mar 1, 2011, at 2:28 PM, Ryan Schmidt wrote:
> 
> On Feb 28, 2011, at 20:33, Arno Hautala wrote:
> 
>> This would also be a good candidate for enhancing the perl5 PortGroup.
>> Automatically "revbump" when the perl5 port is updated. Though this
>> could probably be rolled into the version dependency work.
> 
> The portgroup isn't the appropriate place to do that.

Why not?

> I'm not even sure code to do what you're suggesting is possible in a portgroup. 

Why not?

Looks like portindex uses mportopen. I haven't tested it (yet), but a cursory look at the source seems to
indicate that it should work.

The group file is basically just included into the portfile anyway.

> I think revbumps will have to continue to happen individually in each affected port.

I think it would actually make sense to just set the epoch in the p5 portgroup (say to something like
YYYYMMDDxx). Then only ports that install perl modules that don't use the portgroup would need to be
individually touched.

--
Daniel J. Luke                                                                   
+========================================================+                        
| *---------------- dluke@... ----------------* |                          
| *-------------- http://www.geeklair.net -------------* |                          
+========================================================+                        
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          
+========================================================+

Ryan Schmidt | 1 Mar 22:16 2011

Re: perl5, perl5.* changes

On Mar 1, 2011, at 14:13, Daniel J. Luke wrote:

> On Mar 1, 2011, at 2:28 PM, Ryan Schmidt wrote:
>> 
> 
>> On Feb 28, 2011, at 20:33, Arno Hautala wrote:
>> 
>>> This would also be a good candidate for enhancing the perl5 PortGroup.
>>> Automatically "revbump" when the perl5 port is updated. Though this
>>> could probably be rolled into the version dependency work.
>> 
>> The portgroup isn't the appropriate place to do that.
> 
> Why not?
> 
>> I'm not even sure code to do what you're suggesting is possible in a portgroup. 
> 
> Why not?
> 
> Looks like portindex uses mportopen. I haven't tested it (yet), but a cursory look at the source seems to
indicate that it should work.
> 
> The group file is basically just included into the portfile anyway.

The suggestion was: when the version of perl is updated, all ports using the perl5 portgroup should
automatically have their revisions increased. I don't know how to accomplish that using a portgroup.

Yes, the portgroup is included into the portfile, but at the very top, before anything else in the port has
been executed. Then a few lines further down, the port calls the perl5.setup procedure, passing it the
name and version of the perl module. Then the port might define a revision, if there is one. By the time the
port defines a revision, if any, there are no more calls to the portgroup, thus no chance for it to modify the
revision. And even if there would be a way for it to, say, increment the revision that's already in the
portfile, that would be pretty confusing, wouldn't it? The portfile says version 1.0 revision 1 but in
fact version 1.0 revision 2 gets installed. If the maintainer increases the revision in the portfile to 3,
revision 4 actually gets installed. Nobody would expect
  that. And would such code just stay in the portgroup stay there forever? I don't see how it could ever be removed.

But I can stop thinking about that idea because you proposed a different one:

>> I think revbumps will have to continue to happen individually in each affected port.
> 
> I think it would actually make sense to just set the epoch in the p5 portgroup (say to something like
YYYYMMDDxx). Then only ports that install perl modules that don't use the portgroup would need to be
individually touched.

I had not considered using the epoch, and that might work. It presupposes that no existing port using this
portgroup already has an epoch set higher than this proposed value, but that's not an unreasonable
supposition. It also requires that if a port sets the epoch, it do so before the portgroup, so that the
portgroup can override it. Logically, the epoch has higher precedence than the version, and so should
appear in the portfile on a line above the version, but many existing ports have their epochs on the line
below the version. So we would have to mass-update epochs to ensure they're before versions, and clearly
document this requirement, and also the requirement that p5 ports would need to use an epoch of the same
format that the portgroup uses. (I never really liked seeing the epoch a
 s a date/timestamp because I didn't see any purpose to it, and was going to change the Guide to recommend
simple incrementing integers, like we use for the revision and like many ports use f
 or the epoch, but this suggestion for the perl ports does look like a good use of that.)

Daniel J. Luke | 1 Mar 22:24 2011
Picon

Re: perl5, perl5.* changes

On Mar 1, 2011, at 4:16 PM, Ryan Schmidt wrote:
> 
> The suggestion was: when the version of perl is updated, all ports using the perl5 portgroup should
automatically have their revisions increased. I don't know how to accomplish that using a portgroup.

Well, you could do it the same way as you would with the epoch (I just think it makes more sense to use epoch).

It would still probably require looking at any port that had a revision set already.

>>> I think revbumps will have to continue to happen individually in each affected port.
>> 
>> I think it would actually make sense to just set the epoch in the p5 portgroup (say to something like
YYYYMMDDxx). Then only ports that install perl modules that don't use the portgroup would need to be
individually touched.
> 
> I had not considered using the epoch, and that might work. It presupposes that no existing port using this
portgroup already has an epoch set higher than this proposed value, but that's not an unreasonable
supposition. It also requires that if a port sets the epoch, it do so before the portgroup, so that the
portgroup can override it.

unless you want the portgroup to be able to override the individual ports as well (special magic to set it
only if it's greater than the one in the portfile maybe?)

> Logically, the epoch has higher precedence than the version, and so should appear in the portfile on a line
above the version, but many existing ports have their epochs on the line below the version. So we would have
to mass-update epochs to ensure they're before versions, and clearly document this requirement, and
also the requirement that p5 ports would need to use an epoch of the same format that the portgroup uses.

... but unless we put some code in the portgroup to do special magic, there's still a problem if you ever want
to set epoch in the port

Without any magic, it only requires looking at any ports that do set epoch on their own (as opposed to
rev-bumping or setting epoch on every single port).

--
Daniel J. Luke                                                                   
+========================================================+                        
| *---------------- dluke <at> geeklair.net ----------------* |                          
| *-------------- http://www.geeklair.net -------------* |                          
+========================================================+                        
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          
+========================================================+

Dan Ports | 2 Mar 03:01 2011

Re: perl5, perl5.* changes

I just revbumped all of the ports that build perl5 modules in r76604.

So if you have been having problems, the next 
`port selfupdate && port upgrade outdated` should rebuild quite a few
ports with perl 5.12 and get things working again.

Dan

--

-- 
Dan R. K. Ports              MIT CSAIL                http://drkp.net/
Adam Mercer | 3 Mar 12:06 2011

Re: [76616] trunk/dports/python

On Wed, Mar 2, 2011 at 19:32,  <phw@...> wrote:

> +name                    py27-psyco
> +version                 dev

<snip>

> +fetch.type              svn
> +svn.url                 http://codespeak.net/svn/psyco/branch/py27/

Isn't this a really bad idea, as people who install this at different
times will get different revisions so debugging will be nightmare.

Cheers

Adam
Ryan Schmidt | 3 Mar 16:21 2011

Re: [76623] trunk/dports/php

On Mar 2, 2011, at 19:27, pixilla@... wrote:

> Revision: 76623
>          http://trac.macports.org/changeset/76623
> Author:   pixilla@...
> Date:     2011-03-02 17:27:44 -0800 (Wed, 02 Mar 2011)
> Log Message:
> -----------
> php5-uuid: new port providing php5 pecl uuid extension
> 
> Added Paths:
> -----------
>    trunk/dports/php/php5-uuid/
>    trunk/dports/php/php5-uuid/Portfile
>    trunk/dports/php/php5-uuid/files/
>    trunk/dports/php/php5-uuid/files/patch-osx_build.diff
> 
> Added: trunk/dports/php/php5-uuid/Portfile
> ===================================================================
> --- trunk/dports/php/php5-uuid/Portfile	                        (rev 0)
> +++ trunk/dports/php/php5-uuid/Portfile	2011-03-03 01:27:44 UTC (rev 76623)
>  <at>  <at>  -0,0 +1,21  <at>  <at> 
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
> +# $Id$
> +
> +PortSystem              1.0
> +PortGroup               php5extension 1.0
> +
> +php5extension.setup     uuid 1.0.2 pecl
> +categories-append       net www
> +platforms               darwin
> +maintainers             brad

I think you mean "maintainers pixilla".


Gmane