echo script output to the display

Eric Gallager egall at gwmail.gwu.edu
Thu Sep 25 10:50:03 PDT 2014


On 9/20/14, Ryan Schmidt <ryandesign at 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"...


More information about the macports-dev mailing list