public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "kargl at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/42607] add information about how to compile a module Date: Sun, 04 Apr 2010 20:29:00 -0000 [thread overview] Message-ID: <20100404202827.23709.qmail@sourceware.org> (raw) In-Reply-To: <bug-42607-5724@http.gcc.gnu.org/bugzilla/> ------- Comment #7 from kargl at gcc dot gnu dot org 2010-04-04 20:28 ------- (In reply to comment #5) > (In reply to comment #1) > > > should -c explain how a .mod file is created? > > > > IMHO, the answer is a resounding 'no.' Adding such information > > would simply add unneeded clutter to the manual, and should be > > an insult to anyone that uses Fortran. > > Not documenting the semantics of module files anywhere is a sure way for build > tools like Automake to never get decent support for building Fortran. As it is > now, the user needs to fake dependencies manually to make up for this missing > information. (Where to put the information is another question altogether.) I don't use automake, so I really don't care what it does or does not do. > > Also, the Fortran standard does not require that a .mod be created, > > The Fortran standard is irrelevant for this question. Users want 'make clean' > to remove cruft that 'make' created, and you don't provide a 'gfortran --clean' > to keep information about .mod files under the hood either. > The Fortran standard is the only thing that matters. 'make clean' does the right thing for me. Of course, I know how to write a Makefile without depending on the whim (yes, I wrote whim) of the automake developers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42607
next prev parent reply other threads:[~2010-04-04 20:29 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-01-04 13:30 [Bug fortran/42607] New: " debian-gcc at lists dot debian dot org 2010-01-05 5:49 ` [Bug fortran/42607] " kargl at gcc dot gnu dot org 2010-01-06 14:16 ` burnus at gcc dot gnu dot org 2010-04-02 5:29 ` jv244 at cam dot ac dot uk 2010-04-04 8:40 ` rwild at gcc dot gnu dot org 2010-04-04 15:02 ` jvdelisle at gcc dot gnu dot org 2010-04-04 20:29 ` kargl at gcc dot gnu dot org [this message] 2010-04-05 10:01 ` envite at rolamasao dot org [not found] <bug-42607-4@http.gcc.gnu.org/bugzilla/> 2011-03-05 17:33 ` nightstrike at gmail dot com 2011-03-05 17:58 ` kargl at gcc dot gnu.org 2013-06-24 20:46 ` dominiq at lps dot ens.fr 2013-06-25 18:31 ` anlauf at gmx dot de 2015-08-26 15:20 ` gwhowell at ncsu dot edu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20100404202827.23709.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).