Hi,
I am going to add my 2 cents worth on this topic. Having gotten a new laptop and having had to rebuild AMBER from scratch recently (thank you Jason! -
http://jswails.wikidot.com) I found the verbose output of compilation information difficult to wade through. I was able to debug everything and get my version working on my laptop, but felt that a less verbose compilation would of been fine. That said I am not a coding horse by any stretch of the imagination, but I could see how less experienced folks could be put off with the steady stream of information. In the end I am guessing that most compilations simply go swimmingly (as mine did in the end) and that all of this output is redundant. If someone runs into issues we can tell them to turn on verbose mode to answer the “Please send verbose and verbatim details”. I have no particular axe to grind - besides aesthetics perhaps - but having a clearer “looking” compile for the average Joe user coupled with a verbose version for power users doesn’t seem to me to be such a travesty.
See you all next week!
Kennie
> On Feb 9, 2017, at 2:27 PM, Scott Brozell <sbrozell.rci.rutgers.edu> wrote:
>
> Hi,
>
> I will always build with the verbose output because my many years of user
> support at several institutions and for many softwares can be summarized:
> "Please send verbose and verbatim details."
>
> scott
>
> On Thu, Feb 09, 2017 at 02:17:27PM -0500, Jason Swails wrote:
>> On Thu, Feb 9, 2017 at 1:37 PM, David Cerutti <dscerutti.gmail.com> wrote:
>>
>>> What I was planning was that there would be two options: configure with
>>> -showobj to get the one-line reports of each object, configure with
>>> -showrecipe to get the original output.
>>>
>>
>> ???The names are not particularly intuitive. Why not have one option,
>> "--quiet-build" or something, that turns on this "quiet" version? Most
>> users will pay no attention regardless of how "clean" the output is, and if
>> they have to copy-and-paste error messages to us when they ask questions,
>> I'd rather not have to ask them to reconfigure and recompile with
>> -showrecipe first?
>>
>> That way, people that want to keep the original output can, and those that
>> don't can opt in to --quiet-build.
>>
>> That said, keep in mind that we have so many options already that Dave is
>> already trying to deep-6 some of them. This personally sounds like yet
>> another one of those features that Dave will ask in 3 years "can we just
>> get rid of this?"???, since it's maintenance effort for a feature few are
>> likely to use (just my prediction).
>>
>> All the best,
>> Jason
>>
>>
>>> On Thu, Feb 9, 2017 at 1:22 PM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
>>>
>>>> My 2c: I agree with Jason here. Seeing the full compile command is
>>>> invaluable in tracking down problems. When something breaks you can
>>>> easily find out which directory it happened in and can execute the
>>>> exact command that failed to simplify debugging. Trapping errors is
>>>> easy:
>>>>
>>>> make install 2> compile.err
>>>>
>>>> On Thu, Feb 9, 2017 at 11:58 AM, David Cerutti <dscerutti.gmail.com>
>>>> wrote:
>>>>>
>>>>> 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
>>>>
>>>> If this fails then I actually have to do some work to reconstruct the
>>>> actual command that failed. Granted it's not a lot of work, but with
>>>> the current output I can just copy and paste. Also, not every part of
>>>> Amber uses config.h variables in a sane way, and some programs (like
>>>> pmemd) have their own variables that they use, so the Makefile output
>>>> will have to be custom for many programs, which could be hard to
>>>> maintain if anything changes.
>>>>
>>>> My vote is for the status quo. If others really disagree I at least
>>>> want an option to get the verbose output back.
>>>>
>
> _______________________________________________
> 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 Fri Feb 10 2017 - 13:30:02 PST
