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
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.
Gerald.
On 02/09/2017 01:21 PM, Jason Swails wrote:
> In my personal experience of debugging many-an Amber compilation problems,
> I very frequently found that the verbose output (i.e., having make and the
> compilers print everything it's doing) to be invaluable. At a quick
> glance, at the end of the build, I could check what files were linked, what
> compiler was used, with what libraries and command-line options, at a quick
> glance at the screen or build logs.
>
> This is also true when people come to the list with questions and print
> their build logs. We can catch mistakes like AMBERHOME is not set
> correctly, or the MPI compiler wrappers wrap the gnu compilers when users
> requested intel, ...etc.
>
> If you don't want to miss warnings, you can always turn them into hard
> errors with -Werror, but I'm unconvinced the benefit of a quiet compile
> outweighs the potential downsides.
>
> All the best,
> Jason
>
> On Tue, Feb 7, 2017 at 10:14 PM, David Cerutti <dscerutti.gmail.com> wrote:
>
>> I've settled on my solution for the make recipes. I'm setting the thing
>> generally to .SILENT, but there's an extra variable the Makefile can take
>> as an input argument that will cause one-line names of objects to get
>> printed as the compile, or at a higher setting print the recipes for
>> compiling them just like would normally be seen. The edits to the Makefile
>> are minimal but the user gets a lot more control of how much he or she
>> sees. Now I just need to find out how to put an option in the configure
>> script to carry that argument down from the command line, and I'll be able
>> to replicate the behavior in other Makefiles.
>>
>> Dave
>>
>>
>> On Tue, Feb 7, 2017 at 4:19 PM, Gerald Monard <
>> Gerald.Monard.univ-lorraine.fr> wrote:
>>
>>> Good question!
>>> If you look into sebomd/Makefile, you will find something like this:
>>>
>>> .F90.o:
>>> .echo " [SEBOMD] [F77] [OPT] $<"
>>> .$(FC) $(FPPFLAGS)...
>>>
>>> So I'm only using the @ keyword.
>>> But it seems that there could be a clever way by using the .SILENT
>>> variable. See http://make.mad-scientist.net/managing-recipe-echoing/
>>>
>>> Gerald.
>>>
>>> On 02/07/2017 09:55 PM, Scott Brozell wrote:
>>>> Hi,
>>>>
>>>> How does one get the verbose output to see all the gory details ?
>>>>
>>>> scott
>>>>
>>>> On Tue, Feb 07, 2017 at 03:51:45PM -0500, David Cerutti wrote:
>>>>> .Gerald this looks to be exactly what I'd like to see. Reduces the
>>> output
>>>>> clutter considerably but does not suppress actual errors, or warnings.
>>> I'm
>>>>> going to apply this style to the mdgx and sander builds, then see
>> about
>>>>> branching out.
>>>>
>>>> On Tue, Feb 07, 2017 at 07:53:44PM +0100, Gerald Monard wrote:
>>>>> Not sure it's the answer you want but in the sebomd directory, make
>> will
>>>>> output short lines like
>>>>> [SEBOMD] [F90] [OPT] se_corrections_params.F90
>>>>> [SEBOMD] [F90] [OPT] se_inter.F90
>>>>> [SEBOMD] [F90] [OPT] se_corrections_tools.F90
>>>>> [SEBOMD] [F90] [OPT] se_corrections_module.F90
>>>>> Each line corresponds to a compilation, but you don't see all the long
>>>>> usual compilation lines. This way, it is much easier to see warnings
>> and
>>>>> errors.
>>>>
>>>>
>>>> _______________________________________________
>>>> AMBER-Developers mailing list
>>>> AMBER-Developers.ambermd.org
>>>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>>>
>>>
>>> --
>>> ____________________________________________________________
>>> ________________
>>>
>>> Prof. Gerald MONARD
>>> Directeur d'EXPLOR
>>> Université de Lorraine
>>> Boulevard des Aiguillettes B.P. 70239
>>> F-54506 Vandoeuvre-les-Nancy, FRANCE
>>>
>>> UMR 7565 SRSMC - Equipe TMS
>>> Université de Lorraine, CNRS
>>> Boulevard des Aiguillettes B.P. 70239
>>> F-54506 Vandoeuvre-les-Nancy, FRANCE
>>>
>>> e-mail : Gerald.Monard.univ-lorraine.fr
>>> phone : +33 (0)372.745.279
>>> web : http://www.monard.info
>>>
>>> ____________________________________________________________
>>> ________________
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
--
____________________________________________________________________________
Prof. Gerald MONARD
Directeur d'EXPLOR
Université de Lorraine
Boulevard des Aiguillettes B.P. 70239
F-54506 Vandoeuvre-les-Nancy, FRANCE
UMR 7565 SRSMC - Equipe TMS
Université de Lorraine, CNRS
Boulevard des Aiguillettes B.P. 70239
F-54506 Vandoeuvre-les-Nancy, FRANCE
e-mail : Gerald.Monard.univ-lorraine.fr
phone : +33 (0)372.745.279
web : http://www.monard.info
____________________________________________________________________________
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Feb 09 2017 - 08:00:03 PST
