Jason, what if the quietest version of the compile prints things like this:
Building [MDGX] with:
Compiler = /opt/software/GCC/4.9/bin/gcc
COPTFLAGS = -O3 -mtune=native
CFLAGS = -fPIC -g -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-DBINTRAJ -DHASGZ -DHASBZ2 -D__PLUMED_HAS_DLOPEN
LDFLAGS =
LIBDIR = /mnt/home/cerutti/amber/lib
That's what I'm considering here--I'll commit changes shortly so people can
see how it works. The next level of verbosity prints Gerald's format for
every object built, and the top level returns to printing the full make
recipes for every object. Warnings and errors still get reported no
matter what level of verbosity you're at.
Dave
On Thu, Feb 9, 2017 at 11:03 AM, Jason Swails <jason.swails.gmail.com>
wrote:
> On Thu, Feb 9, 2017 at 10:34 AM, Gerald Monard <
> Gerald.Monard.univ-lorraine.fr> wrote:
>
> > Hi,
> >
> > This idea is just to replace something like:
> > gfortran -Wall -Wno-unused-function -DBINTRAJ -DEMIL -c -O3
> > -mtune=native -fPIC -ffree-form -I../pbsa -I../sqm -I../rism
> > -I../../../include -I/home/amber/amber/amber-local-master/include
> > -I/home/amber/amber/amber-local-master/include -DRISMSANDER -o
> > qm_ewald.o qm_ewald.F90
>
>
> I realize that -- what I was saying is that the paths and options printed
> here (but not below) have often been helpful when I've debugged and
> modified the build. There's a lot of information that's hidden by the
> "cleansed" version below, and my point is that, in my experience, that
> information has been useful on multiple occasions.
>
> by something like:
> >
> > [SANDER] [F90] [OPT] qm_ewald.F90
> >
> > not to silence the full compilation command.
> > That way, I think that it's easier to see warnings and errors.
> > This is also not something uncommon, the linux kernel does it, mpich
> > does it, etc.
> >
>
> I've seen considerably fewer projects do this than not (and on my Linux
> OS, *everything* is built from source). And given how nonstandard our
> build is, I think this information is correspondingly more valuable. It
> does make some warnings harder to see (but not errors, since those break
> the build -- I've *never* had trouble losing errors in a verbose build).
> But it's trivial to turn warnings into errors (which is what I did to fix
> most of sander's compiler warnings).
>
> I don't do much with Amber as a whole anymore, so if I'm the only one that
> used to benefit from the verbose compiler output, then by all means
> suppress it. But I doubt I'm the only one. If people that work on the
> build process find it helpful (which is typically a small number of
> people), then it's probably worth actively *not* changing it.
>
> Just my 2c,
> Jason
>
> --
> Jason M. Swails
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Feb 09 2017 - 09:00:04 PST
