unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann)
Subject: Re: M-x compile for different file extensions
Date: Tue, 22 Oct 2002 08:46:14 +0200	[thread overview]
Message-ID: <84fzuzvumh.fsf@crybaby.cs.uni-dortmund.de> (raw)
In-Reply-To: E183pT3-0000MX-00@fencepost.gnu.org

Richard Stallman <rms@gnu.org> writes:

>     1. There are many independent (small) programs which are
>        not part of a big project and so there is no need for make file.
>
> Isn't a makefile as good a way as any to specify the right commands
> to use to compile them?

I think that people have an irrational fear of Makefiles.  For
example, colleagues were asking me about how to compile C++ programs
from within Emacs for a beginners' course on C++ "without using
makefiles because these are just beginners and not even CS students
and makefiles are so difficult".

Then I explained to them that the empty (or non-existing) makefile is
good enough (if they use GNU make at least, and call their programs
foo.cc).  They were really surprised and the last I heard from them
was "wow, that's simple".

But something that might be useful would be to auto-select a make
target, so that editing foo.cc means that the default command is
"make foo" (or "make -k foo", if you must) and not "make -k".  I
don't know if this is practical.

How about adding some more advertisement for make to the Emacs
documentation somewhere?  Strictly speaking, the Emacs manual is the
wrong spot for this, but maybe it would help a number of users.

[time passes, which is its job]

There is one argument in favor of automatically selecting the right
compile command.  Suppose a user has a lot of *.giggle files and they
want to run "mumblefrotz" on them to produce *.stiffle files.
Suppose that the *.giggle files are all over the place, not just in
one directory.  Then it might be convenient for these users to select
the compile-command based on the major mode of the buffer, instead of
writing makefiles everywhere with basically the same contents.  (The
user might not have the right to edit the global make.rules file.)

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

  reply	other threads:[~2002-10-22  6:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <iPgs9.26259$wU3.2299106@news0.telusplanet.net>
     [not found] ` <200210200000.g9K00B5d021923@beta.mvs.co.il>
2002-10-20 16:59   ` M-x compile for different file extensions Richard Stallman
2002-10-20 18:07     ` Ehud Karni
2002-10-20 19:51       ` Stefan Monnier
2002-10-22  3:12       ` Richard Stallman
2002-10-22  6:46         ` Kai Großjohann [this message]
2002-10-22 17:17           ` Kevin Rodgers
2002-10-22 19:03             ` Ehud Karni
2002-10-23  7:11           ` Richard Stallman
2002-10-22 18:23         ` Ehud Karni
2002-10-23  7:10           ` Richard Stallman
2002-10-20 19:52     ` Stefan Monnier
2002-10-20 22:05       ` Ehud Karni
2002-10-22  3:12       ` Richard Stallman

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84fzuzvumh.fsf@crybaby.cs.uni-dortmund.de \
    --to=kai.grossjohann@cs.uni-dortmund.de \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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).