Re: echo script output to the display
On Oct 11, 2014, at 2:40 PM, Mark Brethen wrote:
On Sep 21, 2014, at 3:32 AM, Ryan Schmidt wrote:
To see the test results, the user could run:
port log --phase test zlib
For the log to still be there after the installation, the user would also
have to have set keeplogs yes. I do this on my main MacPorts installation,
and I periodically run my housekeeping script which deletes logs more than a
month old.
Is there a way to test if keeplogs is set to yes?
Yes, it looks like you can reference ${keeplogs} in a portfile.
___
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 21, 2014, at 3:32 AM, Ryan Schmidt ryandes...@macports.org wrote: To see the test results, the user could run: port log --phase test zlib For the log to still be there after the installation, the user would also have to have set keeplogs yes. I do this on my main MacPorts installation, and I periodically run my housekeeping script which deletes logs more than a month old. Is there a way to test if keeplogs is set to yes? Mark ___ 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: 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: echo script output to the display
Hi folks, On 21 Sep 2014, at 01:21 , Ryan Schmidt ryandes...@macports.org wrote: 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. Of course, not all ports have test suites, and of those that do not all of them pass. Not all maintainers run their ports' test phases either. +1 I remember that we already had a discussion about this topic a while back, in thread [1] Where do I find a good example of a tests” variant (which is really installing the tests on the system)? when I stumbled over this myself. I also would like to have a user-end test phase which would expose test results to the user. Users should be able to opt-in for this by setting a global option enabling these tests. But this would need some serious work on MacPorts’ base code, I figure... Greets, Marko [1] https://lists.macosforge.org/pipermail/macports-dev/2014-March/026202.html ___ 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 21, 2014, at 2:42 AM, Marko Käning wrote: On 21 Sep 2014, at 01:21 , Ryan Schmidt wrote: 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. Of course, not all ports have test suites, and of those that do not all of them pass. Not all maintainers run their ports' test phases either. +1 I remember that we already had a discussion about this topic a while back, in thread [1] Where do I find a good example of a tests” variant (which is really installing the tests on the system)? when I stumbled over this myself. I also would like to have a user-end test phase The existing test phase should be fine. which would expose test results to the user. Users should be able to opt-in for this by setting a global option enabling these tests. But this would need some serious work on MacPorts’ base code, I figure... I've very infrequently tried to run any ports' tests. Partly it's the inconvenience of having to remember to run sudo port test before running sudo port install. If wanting to use a variant, it's harder (having to specify the same variants to both test and install). If wanting to test an upgrade of an already installed port, it's harder (having to determine which variants were specified before, then specifying them again). This would be fixed by offering your proposed global (i.e. macports.conf) setting for automatically running the test phase. The other reason I avoid the tests is that much of the time, the tests would fail. Now what? If I was about to commit an update to the port, should I let a test failure prevent me from committing the update? Should I then have to go back and test the previous version to see if its tests failed too? Failing tests could admittedly indicate real problems in the software, but they could just as easily indicate a test suite that was never tested on OS X. If we offer a setting for automatically running the test phase, I feel we should have a way to print the results of the tests, while not preventing the installation of the port (either always, or via another setting). For example: $ sudo port install zlib --- Computing dependencies for zlib --- Fetching distfiles for zlib --- Verifying checksums for zlib --- Extracting zlib --- Applying patches to zlib --- Configuring zlib --- Building zlib --- Testing zlib: failed --- Staging zlib into destroot --- Installing zlib @1.2.8_0 --- Activating zlib @1.2.8_0 --- Cleaning zlib To see the test results, the user could run: port log --phase test zlib For the log to still be there after the installation, the user would also have to have set keeplogs yes. I do this on my main MacPorts installation, and I periodically run my housekeeping script which deletes logs more than a month old. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: echo script output to the display
Hi Ryan, On 21 Sep 2014, at 10:32 , Ryan Schmidt ryandes...@macports.org wrote: The existing test phase should be fine. yes, it is. I've very infrequently tried to run any ports' tests. Me too, only sometimes it was necessary and I admit that my suggestion might be a little academic, as it is probably only interesting for when the end-user is actually a developer. To see the test results, the user could run: port log --phase test zlib That’s already possible as of now? For the log to still be there after the installation, the user would also have to have set keeplogs yes”. I see. Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: echo script output to the display
Hi, - On 21 Sep, 2014, at 10:38, Marko Käning mk-macpo...@techno.ms wrote: I've very infrequently tried to run any ports' tests. Me too, only sometimes it was necessary and I admit that my suggestion might be a little academic, as it is probably only interesting for when the end-user is actually a developer. I predict enabling testing on a global scale is very likely not what you want. You'd notice it when something pulls in openldap and you're sitting there for hours waiting for the test phase to complete (try it, it's HUGE). To see the test results, the user could run: port log --phase test zlib That’s already possible as of now? Yes, but a failed tests would abort the installation. -- 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
Hi Mark,
On 21 Sep 2014, at 16:36 , Mark Brethen mark.bret...@gmail.com wrote:
What I did was issue a 'make testall' in the post-build phase and put them in
${prefix}/share/${name}/testlogs, and then print a ui message to look at that
directory for the results. I don't think there would be an issue of it failing
if the build was successful,
that sounds like a clean way to do this.
Do you agree, Ryan?
but should this be a variant?
I guess so, yes.
Greets,
Marko
___
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 21, 2014, at 10:36 AM, Mark Brethen mark.bret...@gmail.com wrote:
Well, In this particular case I consider them benchmark tests. What I did was
issue a 'make testall' in the post-build phase and put them in
${prefix}/share/${name}/testlogs, and then print a ui message to look at that
directory for the results.
A slightly better way to run the tests would be to append testall to
build.target.
build.target-append testall
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
Hi Lawrence, On 21 Sep 2014, at 16:45 , Lawrence Velázquez lar...@macports.org wrote: A slightly better way to run the tests would be to append testall to build.target. but this again would mean that a failing test will also fail to install the port. Greets, Marko ___ 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 21, 2014, at 10:50 AM, Mark Brethen mark.bret...@gmail.com wrote:
This is how I currently handle it:
system cd ${cslbuilddir}/csl; exec make testall
Note that this makefile is 2 levels deep from ${worksrcpath}
Do you have to run it from that csl directory? Does the primary makefile not
have an appropriate target?
And is a failed system command in a post-build script considered fatal? I
don't recall off the top of my head. You might have to use catch to get the
behavior you want.
In any case, you should use system -W and build.cmd for this.
system -W ${cslbuilddir}/csl ${build.cmd} testall
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 21, 2014, at 3:32 AM, Ryan Schmidt ryandes...@macports.org wrote: For the log to still be there after the installation, the user would also have to have set keeplogs yes. I didn't see this in the online documentation. Mark ___ 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 21, 2014, at 3:24 PM, Mark Brethen mark.bret...@gmail.com wrote:
On Sep 21, 2014, at 3:32 AM, Ryan Schmidt ryandes...@macports.org wrote:
For the log to still be there after the installation, the user would also
have to have set keeplogs yes.
I didn't see this in the online documentation.
Mark
How's this?
variant test description {CSL test runs} {
post-build {
system -W ${worksrcpath}/scripts ./testall.sh --csl
}
notes-append
A summary of CSL test runs is kept in the main.log file. \
You can manually get the path using
port logfile ${name}
if you have set \keeplogs yes\ in your macports.conf file .
}
Mark
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
echo script output to the display
I have a 'test' variant that will run a script called 'testall.sh' during the
test phase, like so:
variant test description {CSL build tests} {
test.runyes
test {
system cd ${worksrcpath} ./scripts/testall.sh --csl
}
}
However output is directed to the 'main.log' file. Unless the user issues
verbose with the port command they will never see the results. Is it possible
to echo it to the display?
Mark
___
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 20, 2014, at 10:16 AM, Mark Brethen mark.bret...@gmail.com wrote: I have a 'test' variant why? shouldn't you just set test.run and test.cmd (outside of any variants?) -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ 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 20, 2014, at 9:21 AM, Daniel J. Luke dl...@geeklair.net wrote: On Sep 20, 2014, at 10:16 AM, Mark Brethen mark.bret...@gmail.com wrote: I have a 'test' variant why? shouldn't you just set test.run and test.cmd (outside of any variants?) -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ You're thinking it should run automatically instead of user setting? Does that change where the output is sent? Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: echo script output to the display
Hi, - On 20 Sep, 2014, at 16:27, Mark Brethen mark.bret...@gmail.com 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. -- 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 Sep 20, 2014, at 10:30 AM, Clemens Lang c...@macports.org wrote: Hi, - On 20 Sep, 2014, at 16:27, Mark Brethen mark.bret...@gmail.com 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. -- Clemens Lang Is the test phase for debugging? This script tests each math package in a CAS program after build. Would it would make more sense to keep this as a variant and the script at post-build? Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: echo script output to the display
One approach you could use for the test output is to redirect it into a file, and then put a ui message to look at that file for the results. David On Sat, Sep 20, 2014 at 2:11 PM, Mark Brethen mark.bret...@gmail.com wrote: On Sep 20, 2014, at 10:30 AM, Clemens Lang c...@macports.org wrote: Hi, - On 20 Sep, 2014, at 16:27, Mark Brethen mark.bret...@gmail.com 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. -- Clemens Lang Is the test phase for debugging? This script tests each math package in a CAS program after build. Would it would make more sense to keep this as a variant and the script at post-build? Mark ___ 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: echo script output to the display
On Sep 20, 2014, at 2:11 PM, Mark Brethen mark.bret...@gmail.com wrote: On Sep 20, 2014, at 10:30 AM, Clemens Lang c...@macports.org wrote: Hi, - On 20 Sep, 2014, at 16:27, Mark Brethen mark.bret...@gmail.com 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. -- Clemens Lang Is the test phase for debugging? Yes, it's for MacPorts developers. It's not supposed to be used by end-users. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
