Default to gcc49
Now that gcc49 is a stable version, I would like to suggest that ports that currently default to gcc48 be changed to default to gcc49. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
stub keyword
I would like to get a stub keyword into MacPorts base, to make creating stub
ports easier and more consistent, and also to be able to programmatically
identify stub ports.
The default value would be no. Stub ports could then set:
stub yes
This would be equivalent to:
supported_archs noarch
archive_sites
distname
use_configure no
build {}
destroot {
xinstall -d -m 755 ${destroot}${prefix}/share/doc/${subport}
system echo \${name} is a stub port\
${destroot}${prefix}/share/doc/${subport}/README
}
This could be used in the obsolete, perl5, php, and python portgroups and in
the handful of independent stub ports.
If I were writing a Tcl script using the MacPorts API, there should be a way
for me to determine if a port is a stub port.
Perhaps there should also be a way to identify stub ports on the command line.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Python maintenance policy
Maybe not new py24-foo or new py25-foo ports, but what about +python24 or +python25 variants for ordinary ports that have python bindings? For example, this isn't the port itself, but from reading the upstream gdb mailing lists, it looks like gdb upstream actually extended their support for python backwards to python24 with their most recent release this summer (7.8), whereas before they had only supported back to python26... On 9/23/14, Andrea D'Amore and.dam...@macports.org wrote: On Tue, Sep 23, 2014 at 4:46 AM, Lawrence Velázquez lar...@macports.org wrote: == POLICY == […] The policy is informally half in place, noone is actually creating new py24-foo or py25-bar (or at least I hope soo), that said I'm glad to see old py* ports being phased out. This could be handled by the python** portgroups that are already in place after defining stable-version (or latest-stable) variable in the main portgroup. -- Andrea ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Triggering builds on buildbots just by committing to user directory not possible?
Hi, - On 25 Sep, 2014, at 00:27, Joshua Root j...@macports.org wrote: For test builds I would think we want a completely separate MacPorts installation that uninstalls everything between builds. It could upload the archives to somewhere separate as well, and probably delete them from there regularly. Doing this right is a whole can of worms. For example, a user might branch a few ports that depend on each other. Imagine I'd branch ports A, B, C, with dependency relations A - X - B - Y - C The buildbot would then have to rebuild A, B, and C. But, it would also have to rebuild X and Y against my versions of A and B, wouldn't it? -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: echo script output to the display
On 9/20/14, Ryan Schmidt ryandes...@macports.org wrote: On Sep 20, 2014, at 6:18 PM, Lawrence Velázquez wrote: On Sep 20, 2014, at 2:11 PM, Mark Brethen wrote: On Sep 20, 2014, at 10:30 AM, Clemens Lang wrote: You're thinking it should run automatically instead of user setting? Setting test.run and test.cmd doesn't make MacPorts run the tests automatically. You still have to run `sudo port test` explicitly to run tests. Does that change where the output is sent? No. I'm not aware of a proper method to do this, either. You might be able to fiddle with MacPorts' internal verbosity setting, but that would be a hack. Is the test phase for debugging? Yes, it's for MacPorts developers. It's not supposed to be used by end-users. I wouldn't necessarily say that. The test phase tests the software. Users may well want to test that the software they're going to use passes its test suite. I opened a ticket that is kind of related to that (users wanting to know if their software passes its test suite): https://trac.macports.org/ticket/42731 About variants for tests: I usually find myself making a variant for a port's test phase when the test phase needs a dependency that is not needed for any of the other phases (which is https://trac.macports.org/ticket/38208 btw), or if the configure script needs special flags passed to it to be able to run the `test` target properly (which, on another tangent, is actually normally called `check` according to the GNU Coding standards: http://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets . I keep finding myself having to override the default `test.cmd` in my Portfiles to set it to `check` because of this. Also note that this target is listed under Standard Targets for Users, so I think that would be another point of evidence for `port test` being a command for end users to use). About the actual topic of this thread, which is displaying the output of the `system` command in Portfiles: I kinda wish that this output was displayed as well... normally as a half-measure I find myself duplicating all of my calls to `system` in Portfiles: first as a call to `ui_debug`, to show what the call to `system` is actually going to do, and then the actual call to `system` itself. While it might not be quite the same as having the actual output, it can at least function as a crude sort of printf debugging... ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: echo script output to the display
On Sep 25, 2014, at 12:50 PM, Eric Gallager wrote: normally as a half-measure I find myself duplicating all of my calls to `system` in Portfiles: first as a call to `ui_debug`, to show what the call to `system` is actually going to do, and then the actual call to `system` itself. While it might not be quite the same as having the actual output, it can at least function as a crude sort of printf debugging... This is tangential to this thread, but: why don't we make `system` automatically `ui_debug` what it's doing? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: echo script output to the display
On Sep 25, 2014, at 1:50 PM, Eric Gallager eg...@gwmail.gwu.edu wrote: which, on another tangent, is actually normally called `check` according to the GNU Coding standards: http://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets. I keep finding myself having to override the default `test.cmd` in my Portfiles to set it to `check` because of this. You can achieve this with test.target check. Also note that this target is listed under Standard Targets for Users, so I think that would be another point of evidence for `port test` being a command for end users to use). I disagree. Those are merely targets intended to be invoked externally, as opposed to targets for the build's internal use. About the actual topic of this thread, which is displaying the output of the `system` command in Portfiles: I kinda wish that this output was displayed as well I very much dislike this idea as a whole. I don't think any build should be allowed to clutter MacPorts' output without the user explicitly asking for verbose or debug output. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: echo script output to the display
On Sep 25, 2014, at 1:59 PM, Ryan Schmidt ryandes...@macports.org wrote: This is tangential to this thread, but: why don't we make `system` automatically `ui_debug` what it's doing? That occurred to me at some point. I tried looking into it, but `system` seems to be implemented in pextlib, which I'm not comfortable mucking with. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: echo script output to the display
On Sep 25, 2014, at 2:22 PM, Eric Gallager eg...@gwmail.gwu.edu wrote: Pretty sure `ui_debug` only prints when the user uses the `-d` flag (for debug), as opposed to, say, `ui_info`, which always prints. I know `system` swallows output, but I thought the original point was about sending that output to stdout, and not just to the log or wherever. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: echo script output to the display
On 9/25/14, Lawrence Velázquez lar...@macports.org wrote: On Sep 25, 2014, at 2:22 PM, Eric Gallager eg...@gwmail.gwu.edu wrote: Pretty sure `ui_debug` only prints when the user uses the `-d` flag (for debug), as opposed to, say, `ui_info`, which always prints. I know `system` swallows output, but I thought the original point was about sending that output to stdout, and not just to the log or wherever. vq Right, I realize that distinction now; seeing that you had made a separate reply to Ryan helped clarify that for me... ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: dev port or subport?
On Sep 25, 2014, at 2:21 PM, Mark Brethen mark.bret...@gmail.com wrote:
What is the accepted practice for dev ports? I'm porting a program that
currently builds with fox but has the option of building with wxwidgets (i.e.
doesn't require X11). The wx build doesn't have all of the features yet and
should be considered under development. Should this be a separate port or
subport? If subport, how do you set this up as conflicting with port name?
Subports are just an organizational tool. They're meant for cases where two
separate Portfiles would share a significant amount of code. You could do
something like this:
PortSystem 1.0
name foo
version 1.23.45
license TO_KILL
[a lot of common code]
subport foo {
conflicts foo-wx
[foo-specific code]
}
subport foo-wx {
conflicts foo
[foo-devel-specific code]
}
If there isn't all that much shared code, you might be better off with separate
Portfiles.
Ideally you'd also wrangle the builds so that the ports could be installed at
the same time.
vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [125751] trunk/dports/net/daq/Portfile
On Sep 25, 2014, at 2:32 PM, j...@macports.org wrote: Revision 125751 Author j...@macports.org Date 2014-09-25 12:32:08 -0700 (Thu, 25 Sep 2014) Log Message #42243 You should write more detailed commit messages than this. Mentioning the ticket number is great, but you should also say what port it applies to and what you did (i.e. that you updated daq to 2.0.2). This will help those trying to read the commit log later. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: dev port or subport?
On Sep 25, 2014, at 1:44 PM, Lawrence Velázquez wrote:
On Sep 25, 2014, at 2:21 PM, Mark Brethen wrote:
What is the accepted practice for dev ports? I'm porting a program that
currently builds with fox but has the option of building with wxwidgets
(i.e. doesn't require X11). The wx build doesn't have all of the features
yet and should be considered under development. Should this be a separate
port or subport? If subport, how do you set this up as conflicting with port
name?
Subports are just an organizational tool. They're meant for cases where two
separate Portfiles would share a significant amount of code. You could do
something like this:
PortSystem 1.0
name foo
version 1.23.45
license TO_KILL
[a lot of common code]
subport foo {
I was once chastised for writing subport foo when the port's name is foo.
Instead, what we usually write is:
if {${name} eq ${subport}} {
conflicts foo-wx
[foo-specific code]
}
subport foo-wx {
conflicts foo
[foo-devel-specific code]
}
If there isn't all that much shared code, you might be better off with
separate Portfiles.
In my ports so far, I've kept -devel ports as separate portfiles. Partly this
stems from my -devel ports having been created before subports were invented,
but I feel it also has a few advantages. Sometimes projects develop in drastic
ways, resulting in major changes to build systems from one version to the next.
For example, this occurs in my minivmac-devel portfile now, which differs now
from the minivmac portfile. Also, it makes it easier if you actually want there
to be other subports. For example, my graphviz portfile has graphviz-gui and
gvedit subports, and my graphviz-devel portfile has graphviz-gui-devel and
gvedit-devel subports. Getting all 6 into the same portfile would have involved
an outer loop (over -devel and non-devel) and comes with some idiosyncrasies.
I've attempted this strategy once, with the php port, but it makes for a very
complicated port.
Ideally you'd also wrangle the builds so that the ports could be installed at
the same time.
I just want to point out that this applies to your suggested port names foo and
foo-wx, but would not apply to foo and foo-devel ports, which are defined as
installing their files to the same places.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: dev port or subport?
On Sep 25, 2014, at 3:46 PM, Ryan Schmidt ryandes...@macports.org wrote:
I was once chastised for writing subport foo when the port's name is foo.
Instead, what we usually write is:
if {${name} eq ${subport}} {
I've always considered this form to be ugly and obtuse. Is this functionally
different? Or correct in a way that `subport foo` isn't?
vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: echo script output to the display
In my case the benchmark test results ending up in the log file, which is deleted after a successful build, seemed pointless. Sent from my iPhone On Sep 25, 2014, at 1:26 PM, Lawrence Velázquez lar...@macports.org wrote: On Sep 25, 2014, at 2:22 PM, Eric Gallager eg...@gwmail.gwu.edu wrote: Pretty sure `ui_debug` only prints when the user uses the `-d` flag (for debug), as opposed to, say, `ui_info`, which always prints. I know `system` swallows output, but I thought the original point was about sending that output to stdout, and not just to the log or wherever. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: dev port or subport?
On Sep 25, 2014, at 3:16 PM, Lawrence Velázquez wrote:
On Sep 25, 2014, at 3:46 PM, Ryan Schmidt wrote:
I was once chastised for writing subport foo when the port's name is
foo. Instead, what we usually write is:
if {${name} eq ${subport}} {
I've always considered this form to be ugly and obtuse. Is this functionally
different? Or correct in a way that `subport foo` isn't?
Joshua told me he never expected anyone to write that; see this prior
discussion:
https://lists.macosforge.org/pipermail/macports-dev/2012-March/thread.html#18369
Re-reading it to refresh my memory, it seemed that is caused some problem with
getting all the port's subports into the portindex.
IIRC, that was later corrected, but I'm not sure.
Using the if form has the advantage that you can then add an else clause.
This is useful in some situations.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
