[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New Flymake rewrite in emacs-26
From: |
João Távora |
Subject: |
Re: New Flymake rewrite in emacs-26 |
Date: |
Wed, 11 Oct 2017 13:01:41 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.60 (gnu/linux) |
Eli Zaretskii <address@hidden> writes:
>> From: address@hidden (João Távora)
>> Cc: Eli Zaretskii <address@hidden>, Mark Oteiza <address@hidden>, Lele
>> Gaifax <address@hidden>, Leo Liu <address@hidden>, Stefan Monnier
>> <address@hidden>, Emacs developers <address@hidden>
>> 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
- Re: New Flymake rewrite in emacs-26, (continued)
- Re: New Flymake rewrite in emacs-26, João Távora, 2017/10/10
- Re: New Flymake rewrite in emacs-26, Eli Zaretskii, 2017/10/10
- Re: New Flymake rewrite in emacs-26, João Távora, 2017/10/10
- Re: New Flymake rewrite in emacs-26, Noam Postavsky, 2017/10/10
- Re: New Flymake rewrite in emacs-26, João Távora, 2017/10/10
- Re: New Flymake rewrite in emacs-26, Noam Postavsky, 2017/10/10
- Re: New Flymake rewrite in emacs-26, Eli Zaretskii, 2017/10/11
- Re: New Flymake rewrite in emacs-26, Noam Postavsky, 2017/10/11
- Re: New Flymake rewrite in emacs-26, João Távora, 2017/10/11
- Re: New Flymake rewrite in emacs-26, Eli Zaretskii, 2017/10/11
- Re: New Flymake rewrite in emacs-26,
João Távora <=
- Re: New Flymake rewrite in emacs-26, Eli Zaretskii, 2017/10/11
- Re: New Flymake rewrite in emacs-26, João Távora, 2017/10/11
- Re: New Flymake rewrite in emacs-26, Romanos Skiadas, 2017/10/11
- Re: New Flymake rewrite in emacs-26, guillaume papin, 2017/10/11
- Re: New Flymake rewrite in emacs-26, João Távora, 2017/10/12
- Re: New Flymake rewrite in emacs-26, Stefan Monnier, 2017/10/11
- Re: New Flymake rewrite in emacs-26, João Távora, 2017/10/12
- Re: New Flymake rewrite in emacs-26, Stefan Monnier, 2017/10/12
- Re: New Flymake rewrite in emacs-26, João Távora, 2017/10/12
- Re: New Flymake rewrite in emacs-26, Mark Oteiza, 2017/10/11