From: Paul Eggert <eggert@cs.ucla.edu>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: scratch/accurate-warning-pos: next steps.
Date: Tue, 11 Dec 2018 11:59:27 -0800 [thread overview]
Message-ID: <eadb3ffe-4ea6-7d75-48e8-bfec8a439caf@cs.ucla.edu> (raw)
In-Reply-To: <20181211192001.GC4911@ACM>
On 12/11/18 11:20 AM, Alan Mackenzie wrote:
>> If so, aren't we limiting builds to platforms that have binutils,
>> which would be a new restriction?
> Well, we use ld, which also belongs to binutils, and that doesn't seem
> to restrict the platforms. Other platforms surely have equivalents to
> both objdump and ld, and they are/would be used appropriately.
We don't use ld, at least not directly. The makefile uses $(CC), just as
it uses $(CC) to compile. On GNU/Linux hosts this eventually uses ld (or
gold or whatever), but those details are largely immaterial.
If we required objdump or similar utilities, that would be yet another
porting hassle. And we might run into platforms where there is no
objdump-like utility and we have to write one ourselves. This doesn't
sound good at all.
> globals.h seems to manage.
globals.h manages because we decorate every symbol it needs to find. If
we have to decorate every C function that might call EQ (either directly
or indirectly), that would also work but it would be a lot more
intrusive than globals.h is. And the proposal to use objdump seems to
acknowledge this, by proposing a method that wouldn't require such
decoration but would have significant portability problems.
>
>> It should be easy enough to move shared file-static data into another
>> file, that would be compiled only once.
> Possibly not. The same would have to be done with file global data,
> too. But doing it that way would involve a great deal of change to the
> source code (testing for the -D option) which would not be popular.
It'd be less change than having to decorate every function that might
call EQ.
> It would likely slow down the compilation by a very great deal.
That's OK, if the cost is borne only by people who want accurate
diagnostics. People who want compilation speed can simply turn off the
accurate-diagnostics flag.
> You're conflating "tedious" with "tedious in the extreme".
We're estimating how much work would be needed. Even if there would be
more work in changing the byte compiler, it shouldn't be so much more
work that we need to contort all the rest of Emacs. It's better to
localize such changes when possible.
> This would place onerous restrictions on what macros were allowed to do,
> and likely be incompatible with a vast proportion of existing macros.
But under both proposals I mentioned, existing macros would work just
fine with no new restrictions. So what I think you're saying is that if
people want to write macros that allow for more-accurate diagnostics,
they'll find that they can't easily do it for some reason. What reason
would that be? Can you give an example based on some macro already
defined in Emacs?
next prev parent reply other threads:[~2018-12-11 19:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-10 18:00 scratch/accurate-warning-pos: next steps Alan Mackenzie
2018-12-10 18:15 ` Eli Zaretskii
2018-12-10 18:28 ` Alan Mackenzie
2018-12-10 18:39 ` Eli Zaretskii
2018-12-10 19:35 ` Alan Mackenzie
2018-12-10 20:06 ` Eli Zaretskii
2018-12-10 21:03 ` Alan Mackenzie
2018-12-11 6:41 ` Eli Zaretskii
2018-12-11 19:21 ` Stefan Monnier
2018-12-11 19:07 ` Stefan Monnier
2018-12-10 23:54 ` Paul Eggert
2018-12-11 11:34 ` Alan Mackenzie
2018-12-11 18:05 ` Paul Eggert
2018-12-11 19:20 ` Alan Mackenzie
2018-12-11 19:59 ` Paul Eggert [this message]
2018-12-11 20:51 ` Alan Mackenzie
2018-12-11 21:11 ` Stefan Monnier
2018-12-11 21:35 ` Alan Mackenzie
2018-12-11 22:58 ` Stefan Monnier
2018-12-11 21:43 ` Paul Eggert
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=eadb3ffe-4ea6-7d75-48e8-bfec8a439caf@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=acm@muc.de \
--cc=emacs-devel@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.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).