Experimental Physics and
Industrial Control System

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.