From: joaotavora@gmail.com (João Távora)
To: Eli Zaretskii <eliz@gnu.org>
Cc: npostavs@users.sourceforge.net, lele@metapensiero.it,
emacs-devel@gnu.org, mvoteiza@udel.edu, monnier@iro.umontreal.ca,
sdl.web@gmail.com
Subject: Re: New Flymake rewrite in emacs-26
Date: Wed, 11 Oct 2017 13:01:41 +0100 [thread overview]
Message-ID: <87y3oh7v16.fsf@gmail.com> (raw)
In-Reply-To: <831smaoubw.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 11 Oct 2017 13:24:51 +0300")
Eli Zaretskii <eliz@gnu.org> writes:
>> From: joaotavora@gmail.com (João Távora)
>> Cc: Eli Zaretskii <eliz@gnu.org>, Mark Oteiza <mvoteiza@udel.edu>, Lele Gaifax <lele@metapensiero.it>, Leo Liu <sdl.web@gmail.com>, Stefan Monnier <monnier@iro.umontreal.ca>, Emacs developers <emacs-devel@gnu.org>
>> Date: Wed, 11 Oct 2017 01:07:19 +0100
>>
>> Thanks for the idea. Certainly not nonsense, but also not a silver
>> bullet, since Makefiles can invoke gcc in arbitrary ways that fool a
>> guesser. Still, it’s probably decent in a fair amount of cases, and I’m
>> giving it a go to see if it works with Emacs sources and perhaps some
>> other GNU projects. I attach my flag-guessing function at the end.
>>
>> First, my idea is to cache the result of these flags contingent on the
>> Makefile’s location and mtime. This, I think, is doable. Then I use a
>> regexp to extract the gcc invocation from the output.
>>
>> The regexp is very poor but does the job. For the src/fringe.c file the
>> regexp is
>>
>> "gcc[[:space:]]+\\(\\(?:-.*\\)*\\)/path/to/fringe.c"
>>
>> This indeed matches Make’s output and gets me something like this for
>> the match group 1
>>
>> -c -Demacs -I. -I. -I../lib -I../lib -isystem /usr/include/freetype2
>> -isystem /usr/include/alsa -pthread -isystem /usr/include/librsvg-2.0
>> -isystem /usr/include/gdk-pixbuf-2.0 -isystem /usr/include/libpng16
>> -isystem /usr/include/cairo -isystem /usr/include/glib-2.0 -isystem
>> /usr/lib/x86_64-linux-gnu/glib-2.0/include -isystem
>> /usr/include/pixman-1 -isystem /usr/include/freetype2 -isystem
>> /usr/include/libpng16 -isystem /usr/include/libpng16 -isystem
>> /usr/include/libxml2 -isystem /usr/include/dbus-1.0 -isystem
>> /usr/lib/x86_64-linux-gnu/dbus-1.0/include -pthread -isystem
>> /usr/include/glib-2.0 -isystem
>> /usr/lib/x86_64-linux-gnu/glib-2.0/include -isystem
>> /usr/include/glib-2.0 -isystem
>> /usr/lib/x86_64-linux-gnu/glib-2.0/include -isystem
>> /usr/include/freetype2 -isystem /usr/include/freetype2 -isystem
>> /usr/include/freetype2 -MMD -MF
>> deps//home/capitaomorte/Source/Emacs/emacs-26/src/fringe.d -MP -isystem
>> /usr/include/p11-kit-1 -fno-common -W -Wabi -Waddress
>> [... elided many many -W flags]
>> -Wno-type-limits -Wno-unused-parameter -Wno-format-nonliteral -g3 -O2
>>
>> Unfortunately, not all flags make sense for flymake, like the -M family
>> of flags. Ideally, i’d need a way to parse this big string of flags back
>> into, say, an alist, and cherry pick the -I, -D, and -W flags from that
>> set. But I’m afraid split-string will insufficiently deal with escaped
>> spaces in the output.
>>
>> Any ideas?
>
> We are talking about a solution specific to Emacs, right?
No, I was aiming for something more generic that includes at least Emacs
and perhaps otherGNU projects.
But I have no problem in making it work just for Emacs first.
> If so, and assuming that Flymake is already capable of parsing a
> Makefile,
It is not. The only thing it currently knows about Makefiles is what it
has known for many versions, which is to invoke their "check-syntax"
target with a special environment variable set to to a specific
temporary file which contains the buffer's contents. This invocation is
expected to compile files with the correct flags and produce errors and
warnings in the standard output.
> we could simply have somewhere the list of *FLAGS variables from the
> Emacs Makefile that Flymake needs to use. That list will not include
> DEPFLAGS, for example,, which you say make no sense for Flymake. Then
> Flymake could pick up the expanded value of each of these variables,
> and concatenate them.
If we are going to make it specific to Emacs, this sounds more
complicated than adding a "check-syntax" target to the Makefile, which
would bring the (minor) benefit that people using emacs < 26.1 could
also use older Flymake to edit Emacs sources.
João
next prev parent reply other threads:[~2017-10-11 12:01 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-03 14:05 New Flymake rewrite in emacs-26 João Távora
2017-10-03 15:00 ` Eli Zaretskii
2017-10-04 11:58 ` Lele Gaifax
2017-10-04 13:41 ` Lele Gaifax
2017-10-04 16:08 ` João Távora
2017-10-04 16:42 ` Lele Gaifax
2017-10-04 18:11 ` Lele Gaifax
2017-10-05 2:21 ` João Távora
2017-10-05 11:42 ` Lele Gaifax
2017-10-05 23:32 ` Noam Postavsky
2017-10-06 13:16 ` João Távora
2017-10-06 13:24 ` Noam Postavsky
2017-10-06 15:48 ` João Távora
2017-10-07 7:37 ` Lele Gaifax
2017-10-07 16:08 ` João Távora
2017-10-10 12:25 ` João Távora
2017-10-10 14:18 ` Eli Zaretskii
2017-10-10 15:09 ` João Távora
2017-10-10 15:53 ` Eli Zaretskii
2017-10-10 16:25 ` João Távora
2017-10-10 16:40 ` Eli Zaretskii
2017-10-10 17:03 ` João Távora
2017-10-10 17:20 ` Noam Postavsky
2017-10-11 0:07 ` João Távora
2017-10-11 0:59 ` Noam Postavsky
2017-10-11 10:39 ` Eli Zaretskii
2017-10-11 12:16 ` Noam Postavsky
2017-10-11 12:25 ` João Távora
2017-10-11 10:24 ` Eli Zaretskii
2017-10-11 12:01 ` João Távora [this message]
2017-10-11 12:13 ` Eli Zaretskii
2017-10-11 13:41 ` João Távora
2017-10-11 17:49 ` Romanos Skiadas
2017-10-11 18:39 ` guillaume papin
2017-10-12 13:17 ` João Távora
2017-10-11 20:25 ` Stefan Monnier
2017-10-12 13:10 ` João Távora
2017-10-12 13:43 ` Stefan Monnier
2017-10-12 13:56 ` João Távora
2017-10-11 13:11 ` Mark Oteiza
2017-10-10 17:23 ` Eli Zaretskii
2017-10-11 11:11 ` Lele Gaifax
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=87y3oh7v16.fsf@gmail.com \
--to=joaotavora@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=lele@metapensiero.it \
--cc=monnier@iro.umontreal.ca \
--cc=mvoteiza@udel.edu \
--cc=npostavs@users.sourceforge.net \
--cc=sdl.web@gmail.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.