Re: Fwd: Build Failure: (from, 10.6, OS, This, X, builds, configure.compiler=macports-gcc-4.7, newer, on, only, and 6 more

[Clemens Lang]

On Sun, Dec 11, 2016 at 08:14:13PM +0100, René J.V. Bertin wrote:
> > > Just as machine readable as this line. 
> >
> > Wrong, since 'port -q info --line --$fieldname' by definition only
> > contains information on $fieldname, whereas your message contains
> > natural language.
> 
> Clutching at straws much? :)
> 
> Regardless, your argument insinuates something that is true only for a
> subset of the values $fieldname can take on. 

But this subset is exactly the set of values that you'd parse in a
script, whereas you'd usually not parse the ones that contain natural
languge (why would you to split long_description at commata?).

> > That would happen if you were using ui_warn or ui_error.
> 
> So those are not incompatible with the build script?

No, but it would still be wrong to use them to print a message while a
port is opened. Multiple places in MacPorts assume that Portfiles do not
print messages while execution, e.g. dependency calculation,
rev-upgrade, etc.

-- 
Clemens

Re: Fwd: Build Failure: (from, 10.6, OS, This, X, builds, configure.compiler=macports-gcc-4.7, newer, on, only, and 6 more

[René J . V . Bertin]

On Sunday December 11 2016 19:17:13 Clemens Lang wrote:

>> Just as machine readable as this line. 
>
>Wrong, since 'port -q info --line --$fieldname' by definition only
>contains information on $fieldname, whereas your message contains
>natural language.

Clutching at straws much? :)

Regardless, your argument insinuates something that is true only for a subset 
of the values $fieldname can take on. 


>That would happen if you were using ui_warn or ui_error.

So those are not incompatible with the build script?

R.

Re: Fwd: Build Failure: (from, 10.6, OS, This, X, builds, configure.compiler=macports-gcc-4.7, newer, on, only, and 6 more

[Mojca Miklavec]

On 11 December 2016 at 16:53, René J.V. Bertin wrote:
>
> Let me ask once more: is there anything currently available that makes it 
> easier/less work to add variants that select a gcc compiler? I've been 
> looking at the compilers PG, but cannot assess from the preamble comments 
> whether it's meant to do what I'm looking for or not.

Maybe the compilers portgroup indeed does part of what you want, but
you would still have to provide the logic to tell when to switch to a
particular variant.

MacPorts doesn't support building ports with gcc (in particular not
for the sake of supporting C++11). It might work if no C++ interfaces
are used in dependencies / dependents, but your ports might crash if
Qt5 is built against a differest libstdc++.

MP officially supports using libc++. Problems are still to be expected
even then, but it makes more sense to build the port with clang
against libc++ than to suggest using gcc.

Mojca

Re: Fwd: Build Failure: (from, 10.6, OS, This, X, builds, configure.compiler=macports-gcc-4.7, newer, on, only, and 6 more

[René J . V . Bertin]

On Sunday December 11 2016 15:59:13 Clemens Lang wrote:

> 'port info' output is already parsed by scripts today. It's output is
> already machine-readable when using -q info --line --$fieldname. Your
> change breaks this.

Just as machine readable as this line. 

This is mostly as a reaction to Mojca's claim that the current scripts couldn't 
be modified to cope, not to insist on keeping my ui_msg line, but even without 
resorting to using e.g. XML the parser apparently fails because of an 
insufficient set of checks on the input. For instance, my warning message 
contains spaces but no commas, and thus should be rejected as a list of 
subports. Maybe this is what happens, but if so the error doesn't make that 
clear at all.

One other usual thing that be done is ensuring that ui_* print to a different 
stream than the one `port -q info --line` prints to. I would hope that Tcl 
doesn't make that needlessly difficult.


Let me ask once more: is there anything currently available that makes it 
easier/less work to add variants that select a gcc compiler? I've been looking 
at the compilers PG, but cannot assess from the preamble comments whether it's 
meant to do what I'm looking for or not.

Alternatively I'll just leave things as they were, i.e. no special treatment 
for 10.6 .

R

Re: Fwd: Build Failure: (from, 10.6, OS, This, X, builds, configure.compiler=macports-gcc-4.7, newer, on, only, and 6 more

[Clemens Lang]

On Sun, Dec 11, 2016 at 03:38:14PM +0100, René J.V. Bertin wrote:
> > Because it runs 'port -q info --line --subports' and parses the
> > result. The flags to info guarantee that only the list of subports
> > is printed.
> 
> Portindex? I'm pretty sure I've had a ui_msg for a while in one of my
> PortGroups without ever running into side-effects. I kind of
> appreciate certain messages in the portindex output, in fact.

No, the buildbot scripts. The rule still stands: Don't print anything
from a Portfile outside of a phase.

> On Sunday December 11 2016 14:59:52 Mojca Miklavec wrote:
> 
> > There is no way to fix the buildbot scripts to work around that.
> 
> I doubt that, esp. not if you consider the possibility (and overall
> good idea) to extent `port info` to print information for machine
> reading.

'port info' output is already parsed by scripts today. It's output is
already machine-readable when using -q info --line --$fieldname. Your
change breaks this.

-- 
Clemens

Re: Fwd: Build Failure: (from, 10.6, OS, This, X, builds, configure.compiler=macports-gcc-4.7, newer, on, only, and 6 more

[René J . V . Bertin]

On Sunday December 11 2016 14:56:23 Clemens Lang wrote:

> Two options:
> 
> 1. Modify port(1) to print notes before installation of a port

I've volunteered to help find a solution to this situation, but with the 
underwhelming reception that got I'm not that enchanted to insist.


> Because it runs 'port -q info --line --subports' and parses the result.
> The flags to info guarantee that only the list of subports is printed.

Portindex? I'm pretty sure I've had a ui_msg for a while in one of my 
PortGroups without ever running into side-effects.
I kind of appreciate certain messages in the portindex output, in fact.

On Sunday December 11 2016 14:59:52 Mojca Miklavec wrote:

> There is no way to fix the buildbot scripts to work around that.

I doubt that, esp. not if you consider the possibility (and overall good idea) 
to extent `port info` to print information for machine reading.

> I find that ui_msg a bit strange, one should fix the code and either
> predict that the build would work or fail straight away. But until
> that part is fixed, I surrounded the code with "pre-fetch { ... }" to
> avoid problems like the one seen above.

As I said, I do not want to disallow building the port on a standard 10.6 
because that worked just fine when I was still running 10.6 myself. I can 
confirm now that gcc 4.7+ still builds the code. Evidently I cannot run it on 
10.9 because of a C++ runtime conflict that won't exist on 10.6 .
A pre-fetch fail is acceptable only if there's a way to introduce a variant 
that will let the code build with an appropriate gcc compiler of choice.

> But as you probably noticed none of the subports currently build on
> the 10.6 buildbots anyway:

Yes, I noticed one reason which Marko had caught before pushing (but without 
leaving me the time to address it). The Qt5 subport will probably fail because 
there currently is no Qt5 for 10.6, but that applies to all Qt5 dependents.
That's all I've been able to glean from the ragtag buildbot output that's been 
flooding my MacPorts in folder.

R.

Re: Fwd: Build Failure: (from, 10.6, OS, This, X, builds, configure.compiler=macports-gcc-4.7, newer, on, only, and 6 more

[Clemens Lang]

On Sun, Dec 11, 2016 at 02:28:14PM +0100, René J.V. Bertin wrote:
> > A Portfile should not should not print anything in response to it
> > simply being opened. (Think about it, does a user really want to see
> > this message whenever they run 'port info'
> 
> Yes they are supposed to! Cf. #52981

No, you even said that in the ticket:

"""
the information shouldn't be printed unconditionally because then it
most certainly would show up at inappropriate times like when running
portindex
"""

Your change made the information show up at an inappropriate time.
Remember that even though a user runs 'port info', they might limit the
output of that, e.g. using 'port -q info --line --subports'. There is no
way to get this right from a Portfile; you must declare the information
you want to be printed in a field and implement support for printing
this field in the port client, rather than attempting to hack around
this in the Portfile.

> This message should ideally be delivered before a user starts trying
> to install the port, or else when a build failure occurs.

Two options:

1. Modify port(1) to print notes before installation of a port
2. Add the information to the long_description of a port, which will be
   visible on 'port info'.

> > The script that finds out which subports exist has to open the port
> > to do so, and prints the list of subports to stdout.
> 
> but why would it consider the output from a ui_msg statement as a list
> of subports? It's never done that for me, and I'd call that a bug, no
> matter how not-done it is to use ui_msg in a port's common code.

Because it runs 'port -q info --line --subports' and parses the result.
The flags to info guarantee that only the list of subports is printed.
You violate this assumption by printing more output in ports. Don't.

-- 
Clemens

Re: Fwd: Build Failure: (from, 10.6, OS, This, X, builds, configure.compiler=macports-gcc-4.7, newer, on, only, and 6 more

[Joshua Root]

On 2016-12-11 23:30 , René J.V. Bertin wrote:

On Sunday December 11 2016 12:45:44 Marko Käning wrote:



My goodness, what happened here???


That seems to come from this line

ui_msg "This port only builds with configure.compiler=macports-gcc-4.7 (from 
port:gcc47) or newer on OS X 10.6"

I put that in instead of simply invoking the cxx11 PortGroup because Mojca 
considered I'd have to test that (which I can't).

Should I conclude that the build bots cannot handle unforeseen output but try 
to parse it instead?


A Portfile should not should not print anything in response to it simply 
being opened. (Think about it, does a user really want to see this 
message whenever they run 'port info' or portindex?) The script that 
finds out which subports exist has to open the port to do so, and prints 
the list of subports to stdout.


- Josh

Re: Fwd: Build Failure: (from, 10.6, OS, This, X, builds, configure.compiler=macports-gcc-4.7, newer, on, only, and 6 more

[René J . V . Bertin]

On Sunday December 11 2016 12:45:44 Marko Käning wrote:


> My goodness, what happened here???

That seems to come from this line

ui_msg "This port only builds with configure.compiler=macports-gcc-4.7 
(from port:gcc47) or newer on OS X 10.6"

I put that in instead of simply invoking the cxx11 PortGroup because Mojca 
considered I'd have to test that (which I can't).

Should I conclude that the build bots cannot handle unforeseen output but try 
to parse it instead?

> Begin forwarded message:
> 
> > From: build...@macports.org
> > Subject: Build Failure: (from, 10.6, OS, This, X, builds, 
> > configure.compiler=macports-gcc-4.7, newer, on, only, and 6 more
> > Date: 11 Dec 2016 12:43:10 GMT+1
> > To: mcalh...@macports.org, m...@macports.org, rjvber...@gmail.com
> > Cc: macports-bui...@lists.macports.org
> > Reply-To: nore...@macports.org
> > 
> > Status:   Failure
> > Build slave:  ports-10.6_i386_legacy
> > Full logs:
> > https://build.macports.org/builders/ports-10.6_i386_legacy-watcher/builds/3479
> > Build reason: The SingleBranchScheduler scheduler named 'ports' triggered 
> > this build
> > Port list:qtcurve
> > Subport list:
> > - (from
> > - 10.6
> > - OS
> > - This
> > - X
> > - builds
> > - configure.compiler=macports-gcc-4.7
> > - newer
> > - on
> > - only
> > - or
> > - port
> > - port:gcc47)
> > - qtcurve-qt5
> > - with
> > Variants: None
> > Revision: fcb150809ae811167b97bce5a002729a9fafc80c
> > Build time:   0:03:29
> > Committer:Marko Käning