1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 <2019> 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 <2019> 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: convertRelease.pl checkRelease printing on stdout vs. stderr |
From: | "Johnson, Andrew N. via Tech-talk" <[email protected]> |
To: | "[email protected]" <[email protected]> |
Date: | Wed, 8 May 2019 17:27:39 +0000 |
We have some build rules that suppress additional status output when you use the “-s” switch, so that is definitely the recommend way to cut down on unnecessary output from the build. We also support parallel builds using GNUmake's “-j n” flag, although some support modules may lack some of the necessary dependency information so I can't promise it works everywhere. When it works though this saves a lot of time on a machine that has multiple CPUs available. I do recommend providing a limit n unless your machine has lots of CPUs though, I can hang my personal 2*2 CPU Linux laptop with a “make -sj” because the build starves the OS processes of CPU long enough for something to not recover properly. My 12*2 CPU desktop machine at work handles it fine though. On Windows you should always provide a numeric limit as well, GNUmake's "too-busy" detector doesn't work properly there. - Andrew On 5/8/19 9:53 AM, Hinko Kocevar via Tech-talk wrote:
Thanks Mark, just changed to use the -s switch and it works as expected! //hinko ________________________________________ From: Mark Rivers <[email protected]> Sent: Wednesday, May 8, 2019 2:35:47 PM To: Hinko Kocevar Cc: [email protected] Subject: Re: convertRelease.pl checkRelease printing on stdout vs. stderr Hi Hinko,The reason is that I use `make install >/dev/null` no to see all the cruft during compilation, but only errors/warnings.The output of `convertRelease.pl checkRelease` is on stdout hence not seen in my case. I would like to see it though..I am not disagreeing with you, but I think there is already another way to achieve what you want. Rather than this: make install >/dev/null do this: make -s install If you do that you will only see errors/warnings, but you will still see the messages from checkRelease. I just tested that. Mark ________________________________ From: [email protected] <[email protected]> on behalf of Hinko Kocevar via Tech-talk <[email protected]> Sent: Wednesday, May 8, 2019 7:19 AM To: [email protected] Subject: convertRelease.pl checkRelease printing on stdout vs. stderr Would the messages from `convertRelease.pl checkRelease` be better off seen on the stderr, as opposed to stdout? I think that is what I'm seeing on Linux builds. The reason is that I use `make install >/dev/null` no to see all the cruft during compilation, but only errors/warnings. The output of `convertRelease.pl checkRelease` is on stdout hence not seen in my case. I would like to see it though.. All the text between 'Definition of..' and 'make[2]: *** [checkRelease] Error 1' is on stdout: make -C ./configure install make[1]: Entering directory `/home/gitlab-runner/bde/R3.15.5/bpmioc-mebt/configure' make -C O.linux-x86_64 -f ../Makefile TOP=../.. \ T_A=linux-x86_64 install make[2]: Entering directory `/home/gitlab-runner/bde/R3.15.5/bpmioc-mebt/configure/O.linux-x86_64' perl -CSD /opt/bde/R3.15.5/artifacts/epics-base-R3.15.5/bin/linux-x86_64/convertRelease.pl checkRelease Definition of ADSUPPORT conflicts with IOCAPP support. In this application a RELEASE file defines ADSUPPORT = /opt/bde/R3.15.5/artifacts/adsupport-master but IOCAPP at /opt/bde/R3.15.5/artifacts/bpmapp-mebt defines ADSUPPORT = /opt/bde/R3.15.5/artifacts/adsupport-R1-4 Definition of ADSIS8300 conflicts with IOCAPP support. In this application a RELEASE file defines ADSIS8300 = /opt/bde/R3.15.5/artifacts/adsis8300-bpm but IOCAPP at /opt/bde/R3.15.5/artifacts/bpmapp-mebt defines ADSIS8300 = /opt/bde/R3.15.5/artifacts/adsis8300-master Definition of ASYN conflicts with IOCAPP support. In this application a RELEASE file defines ASYN = /opt/bde/R3.15.5/artifacts/asyn-master but IOCAPP at /opt/bde/R3.15.5/artifacts/bpmapp-mebt defines ASYN = /opt/bde/R3.15.5/artifacts/asyn-R4-33 Definition of ADSUPPORT conflicts with BPMAPP support. In this application a RELEASE file defines ADSUPPORT = /opt/bde/R3.15.5/artifacts/adsupport-master but BPMAPP at /opt/bde/R3.15.5/artifacts/bpmapp-mebt defines ADSUPPORT = /opt/bde/R3.15.5/artifacts/adsupport-R1-4 Definition of ADSIS8300 conflicts with BPMAPP support. In this application a RELEASE file defines ADSIS8300 = /opt/bde/R3.15.5/artifacts/adsis8300-bpm but BPMAPP at /opt/bde/R3.15.5/artifacts/bpmapp-mebt defines ADSIS8300 = /opt/bde/R3.15.5/artifacts/adsis8300-master Definition of ASYN conflicts with BPMAPP support. In this application a RELEASE file defines ASYN = /opt/bde/R3.15.5/artifacts/asyn-master but BPMAPP at /opt/bde/R3.15.5/artifacts/bpmapp-mebt defines ASYN = /opt/bde/R3.15.5/artifacts/asyn-R4-33 make[2]: *** [checkRelease] Error 1 make[2]: Leaving directory `/home/gitlab-runner/bde/R3.15.5/bpmioc-mebt/configure/O.linux-x86_64' make[1]: *** [install.linux-x86_64] Error 2 make[1]: Leaving directory `/home/gitlab-runner/bde/R3.15.5/bpmioc-mebt/configure' make: *** [configure.install] Error 2 Thanks, Hinko Kocevar Beam Diagnostics Engineer European Spallation Source ERIC P.O Box 176, SE-221 00 Lund, Sweden Visiting address: Odarslövsvägen 113, SE-224 84 Lund , Sweden Mobile: +46-721-79 22 58 Phone: +46-46-888 32 58 E-mail: [email protected] Web: www.esss.se<http://www.esss.se> -- Complexity comes for free, Simplicity you have to work for. |