emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Eric Schulte <eric.schulte@gmx.com>
To: Achim Gratz <Stromeko@nexgo.de>
Cc: emacs-orgmode@gnu.org
Subject: Re: Org Build System (aka Makefile)
Date: Mon, 13 Aug 2012 07:16:18 -0600	[thread overview]
Message-ID: <87boifrkyl.fsf@gmx.com> (raw)
In-Reply-To: <87zk5zdery.fsf@Rainer.invalid> (Achim Gratz's message of "Sun, 12 Aug 2012 22:41:21 +0200")

Achim Gratz <Stromeko@nexgo.de> writes:

> Eric Schulte writes:
>> But we certainly shouldn't (and currently aren't?) inhibit the display
>> of any warnings when the default make is run.  I was surprised to run
>> make compile-source and see additional warnings which weren't shown
>> during regular make.
>
> These warnings aren't reliable — the byte compiler doesn't really try to
> find and report problems.
>

Understood, however they are still a useful check, especially after
large code changes or during code cleanup.  In fact, because I never run
compiled Org-mode, these checks are one of my main uses of the Makefile.

>
>> What is the difference between "make" and "make
>> compile-source" which results in different warnings?
>
> make -n compile
> make -n _COMPILE_=single compile
>
> The difference is starting a single Emacs and then compiling all files
> vs. starting a fresh Emacs instance for each file to be compiled.  The
> change was originally triggered by some differences to the builds in
> package manager (ELPA) and solidified due to the fact that this is the
> only method that does function with only Emacs available.  Should have
> been discussed around November last year, IIRC.
>

Thanks for clarifying.  It certainly does sound like we are using the
correct default build option.  It would be preferable if the Emacs
compilation process produced more predictable warnings, but I doubt this
is a high priority for the busy core Emacs devs.

>
>> After some time digging through the make files, it looks to me like one
>> must edit the local.mk file to run these.
>
> You are welcome to dig through whatever files, but maybe you might
> consult the documentation first?

I don't find the strings "single compile", "compile-source" or "elint"
anywhere in the Org documentation.  Perhaps there is different
documentation for the Makefile?

> As you would read there and can see above, you can do it all on the
> command line if you wish.  If you want to enact that change
> permanently, you should edit local.mk — that's the only reason it
> exists.
>
>> I'd propose that they are added as a separate Makefile target
>> (mentioned by "make help") so that they can be easily run.
>
> If you want additional make targets you can also implement those in
> local.mk; run `make helpall´ some time and ask yourself if you really
> need more.
>

Despite the huge number of Makefile targets (do we really need 12
different versions of "make clean"), I do think that a make target to
run a static code check would be useful.

>
>> Very few people (users or developers) are willing to edit make
>> configuration files.
>
> Those same people that have no problem to edit the sources?  Come on,
> you can't be serious.
>

I am one of these people and I am completely serious.  This is the first
time I've looked at Org-mode's make system -- beyond my help with the
test infrastructure.

The Makefile uses different languages and has different goals than the
source code and I think there are many who feel comfortable editing one
but not the other.  If you'll permit me an exaggerated metaphor, asking
developers to edit a Makefile is like asking a watch maker to rebuild
the table in her workshop.  She will likely find the task to be a waste
of time, to be outside of her core competency, and not directly related
to her real work, even if it results in a more comfortable work
environment.

>
>> Perhaps these elint build options should be used to build when "make
>> check" is run.  If a user is willing to run the test suite they should
>> be willing to endure a slower build for more thorough warnings.
>
> If they want to, they can edit local.mk.

As I continue to contend, editing local.mk simply will not happen in
most cases.

> But since it is not necessary for the build and there won't be any
> warnings to see if the developers do a good job, it's not a useful
> default.  It is maybe useful as an additional configuration for
> release tests (just as it is useful to have multiple configurations to
> be able to test different versions of Emacs).
>

Having spent some time playing around with the elint options, I withdraw
my suggestion that this should be the default for running "make test" as
it is often simply too slow, however, I do think it should be exposed as
a make file target (listed by "make help"), or in some way made possible
without requiring esoteric configuration (either on the command line or
in local.mk).

Thanks for your patient explanations and consideration.

>
>
> Regards,
> Achim.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

  reply	other threads:[~2012-08-13 13:16 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-15 20:37 Org Build System (aka Makefile) Achim Gratz
2012-07-15 21:38 ` Bastien
2012-08-09 17:03 ` Achim Gratz
2012-08-10  7:17   ` Bastien
2012-08-12 13:56     ` Achim Gratz
2012-08-12 18:56       ` Eric Schulte
2012-08-12 20:41         ` Achim Gratz
2012-08-13 13:16           ` Eric Schulte [this message]
2012-08-13 13:45             ` Bastien
2012-08-13 19:27               ` Achim Gratz
2012-08-13 22:43                 ` Eric Schulte
2012-08-14  6:13                   ` Achim Gratz
2012-08-14 12:46                     ` Eric Schulte
2012-08-14 22:06                     ` Bastien
2012-08-15 16:35                       ` Achim Gratz
2012-08-14 22:45                 ` Bastien
2012-08-15 17:55                   ` Achim Gratz
2012-08-15 18:56                     ` Bastien
2012-08-13 19:47             ` Achim Gratz
2012-08-14 22:07               ` Bastien
2012-08-12 22:27       ` Bastien
2012-08-13  6:11         ` Achim Gratz
2012-08-13  7:40           ` Bastien
2012-08-13 11:42             ` Achim Gratz
2012-08-13 13:13               ` Bastien
2012-08-13 14:17                 ` Achim Gratz
2012-08-13 14:48                   ` Bastien
2012-08-13 18:56                     ` Achim Gratz
2012-08-13  5:34       ` Bastien
2012-08-12 16:58     ` Samuel Wales

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.orgmode.org/

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

  git send-email \
    --in-reply-to=87boifrkyl.fsf@gmx.com \
    --to=eric.schulte@gmx.com \
    --cc=Stromeko@nexgo.de \
    --cc=emacs-orgmode@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: 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/org-mode.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).