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 th
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 wrote:
>
>> On Sep 25, 2014, at 2:22 PM, Eric Gallager wrote:
>>
>> Pretty sure `ui_debug` only
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 "co
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
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
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 c
On 9/25/14, Lawrence Velázquez wrote:
> On Sep 25, 2014, at 2:22 PM, Eric Gallager 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
On Sep 25, 2014, at 2:22 PM, Eric Gallager 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,
On 9/25/14, Lawrence Velázquez wrote:
> On Sep 25, 2014, at 1:50 PM, Eric Gallager 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
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
On Sep 25, 2014, at 1:59 PM, Ryan Schmidt 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 comfortab
On Sep 25, 2014, at 1:50 PM, Eric Gallager 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 defau
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
On 9/20/14, Ryan Schmidt 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?
Settin
On Sep 25, 2014, at 8:50 AM, Eric Gallager wrote:
> Maybe not new py24-foo or new py25-foo ports, but what about +python24
> or +python25 variants for ordinary ports that have python bindings?
I'm not sure what you're asking. I don't think people are introducing new
variants either. In any case
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
>
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
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 no
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
19 matches
Mail list logo
