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

Proposal: variants naming conventions
by Randall Wood 12 Feb '07

12 Feb '07

I have noticed that most variants add or delete a configure flag in the form of --enable-*/--disable-*/--with-*/--without-* and maybe add or delete a related dependency. Therefore, I propose that all variants should fit the following forms: {en|dis}able_package: If a ported software package has optional compile-time features, the user can give configure command line options to specify whether to compile them. The options have one of these forms: --enable-feature --disable-feature (Note that this is slightly different then how configure scripts work [1]). with[out]_package: When a port requires, or can optionally use, other ports that can be or already are installed. The user can give configure command line options to specify which such external software to use. A port can be written with options have one of these forms: +with_package +without_package (Note that this is slightly different then how configure scripts work [2]). (Most configure scripts allow these options to passed with further information in the form of --option=arg where a reasonable default is set if =arg is not specified. port can't handle that, so =arg is not allowed in variant names and this proposal does not contemplate changing that) Changing this variant structure has, I believe, the following benefits: 1) Adding the verb enable/disable/use/with/without makes the variant more meaningful to users. I know there have been comments on the mailing list about the inability to comment on variants such that 'port info' is capable of explaining what each variant does. The verb will help address those complaints. 2) There are currently variants no-*, no_*, and no* These are inconsistent and do not tell me (the user) if I am disabling a feature (that some other port may depend on) or simply building the port without using some other package. 3) Negative variants are confusing. with_*/without_* or enable_*/ disable_* is more readable than +*/-* as an indicator of what is going on. References: [1] GNU Autoconf Manual Section 12.2: Choosing Package Options, http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_mono/ autoconf.html#SEC131 [2] GNU Autoconf Manual Section 12.1: Working With External Software, http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_mono/ autoconf.html#SEC130 Randall Wood rhwood(a)mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

2 2

I am writing a Portfile and i would appreciate help
by Andrea Cimino 11 Feb '07

11 Feb '07

I am writing a Portfile for the "Parma Polyhedra Library" project (http://www.cs.unipr.it/ppl) but i have some questions for you, developers. You can find a first snapshot of the Portfile here: http://www.cs.unipr.it/cgi-bin/viewvc/viewvc.cgi/ppl/DarwinPorts_Portfile?r… This is my first Portfile so i don't expect that meets the MacPorts standards, here the questions: 1) Is really needed to have a ppl-dev package, with headers and so on? Or we can just provide a 'ppl' package with everything installed there? 2) The 'ppl' provides several Prolog interfaces so i decided to write some variants: is this the right way to help MacPorts users installing the 'ppl' and building the interfaces? 3) The 'ppl', depending on the presence of the 'glpk' library, builds the optional tool 'ppl_lpsol'. The glpk dependency should be declared in a variant or in the main section of the Portfile? Other suggestions obviously are welcome! Best regards, Andrea Cimino

3 5

Revamping home page left sidebar
by Blair Zajac 11 Feb '07

11 Feb '07

Regarding the left sidebar of links on http://www.macports.org/ I have some suggestions. The term "Source Code" is not as obvious as "Download" which people are more familiar with. We can say, we only provide source downloads, no binaries. Also, adding links to the the users, developers, ticket (bug report) changes, and source code changes mailing lists would be nice, so you don't have to hunt down the home page. Regards, Blair

2 1

zile port update
by Michael Stevens 11 Feb '07

11 Feb '07

Hi. I've updated the zile port to version 2.2.28. The change is in trac as ticket #11370: http://trac.macosforge.org/projects/macports/ticket/11370 Michael

2 1

Latest vim upgrade screws up aqua variant?
by Thomas Zander 11 Feb '07

11 Feb '07

Good day, since the vim port has been bumped to patchlevel 192, the aqua variant seems to have problems: E484: Can't open file /opt/local/Vim.app/Contents/Resources/vim/syntax/syntax.vim So it seems gvim looks for syntax highlighting definitions at the wrong place. Also the main menu does not have any entries except for the leftmost "vim". This happens under a recent OS X Tiger, Intel Mac. Building vim without aqua support however works fine. Has somebody else encountered this? Regards, Riggs

2 5

Anyone watching the bugtracker ?
by Jann Röder 10 Feb '07

10 Feb '07

Hello everyone, I'm wondering what the policy regarding updated ports / new ports and other patches on the bugtracker is. It seems to me that if you don't bother anyone with commit rights about commiting your update/new port it will never be put in the ports tree. There appear to be countless (valid) tickets that nobody even commented on. This seems a bit discouraging for new contributers. I don't want to accuse anyone, I just thought it might be good to bring up this topic. Cheers Jann

2 1

Spring-cleaning @opendarwin.org addresses
by Weissmann Markus 09 Feb '07

09 Feb '07

Hi folks, to clean up some stale maintainerships, we will do a mass-update to Portfiles on 01. march and replace all @opendarwin.org maintainers with the nomaintainer@ tag. Most ports that still have @opendarwin.org maintainers are probably abandoned and for those who are not: You have one month left to (i) replace the address with your new (probably @macports.org) address or (ii) complain that you'll stick with your @opendarwin.org address and we should not nuke your maintainerships. In the meantime, @opendarwin.org maintainerships are not free to be nuked, you may take over maintainership of ports AFTER the reset to nomaintainer@. salut, -Markus --- Markus W. Weissmann http://www.mweissmann.de/ http://www.macports.org/

3 3

svn macports - can not find pextib
by CHENG Gao 06 Feb '07

06 Feb '07

Sorry if this problem was reported already. If not, I'll report my finding. With fresh installation of svn MacPorts (1.40), sudo port sync or port selfupdate reports error message that pextlib 1.0 can not be found. While 1.3.2 works well. This problem wont occur if you install 1.40 over existed version. It's with svn source of yesterday.

2 1

Re: [21762] trunk/base/src/port1.0/resources/group/xcode-1.0.tcl
by Juan Manuel Palacios 06 Feb '07

06 Feb '07

On Feb 5, 2007, at 7:20 PM, source_changes(a)macosforge.org wrote: > Revision > 21762 > Author > eridius(a)macports.org > Date > 2007-02-05 15:20:58 -0800 (Mon, 05 Feb 2007) > > Log Message > Add OBJROOT and SYMROOT args to xcodebuild to ensure it builds within > the work dir. > Redefine destroot.destdir instead of passing DSTROOT manually to avoid > the useless DESTDIR arg to xcodebuild; also, it's cleaner this way > > Modified Paths > • trunk/base/src/port1.0/resources/group/xcode-1.0.tcl Hey Kevin! I just checked in a revised base/doc/portgroup.7 file to add Yves' gnustep PortGroup documentation, you think you could please hack on it to adapt the Xcode PortGroup documentation to the changes your commit here implies, if any? Thanks! -jmpp

2 2

Re: SourceForge in mirror_sites.tcl
by Juan Manuel Palacios 06 Feb '07

06 Feb '07

On Feb 5, 2007, at 9:33 PM, Ross Turk wrote: > I think that depends on the geographical breakdown of your users. If > you have mostly users in the US, I would choose easynews (AZ), superb > (VA), and umn (MN). If your audience skews global, you should > probably pick easynews (US), kent (UK), ufpr (Brazil), and jaist > (Japan). Hey Ross! Yeah, I think it's safe to assume we have users all around the globe (/me inflates chest! ;-), so I chose your worldwide distribution. Our SourceForge mirrors list will look like this when MacPorts 1.4 is released: set portfetch::mirror_sites::sites(sourceforge) { http://downloads.sourceforge.net/ http://easynews.dl.sourceforge.net/ http://ufpr.dl.sourceforge.net/ http://kent.dl.sourceforge.net/ http://jaist.dl.sourceforge.net } Do inform/warn me if I need to make any additins/corrections! > > Thanks for doing this! I appreciate it. :) Thanks to you for the info, toggling the mirrors list manually whenever something happened to a particular mirror was becoming a bit of a problem ! > > Thx, > Ross > -- > Ross Turk, Community Manager > <ross(a)sourceforge.net> -jmpp

1 0