unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: joaotavora@gmail.com (João Távora)
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:24:51 +0300	[thread overview]
Message-ID: <831smaoubw.fsf@gnu.org> (raw)
In-Reply-To: <87a80y8s3s.fsf@gmail.com> (joaotavora@gmail.com)

> 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?  If so, and
assuming that Flymake is already capable of parsing a Makefile, 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.



  parent reply	other threads:[~2017-10-11 10:24 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 [this message]
2017-10-11 12:01                       ` João Távora
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

  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=831smaoubw.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=joaotavora@gmail.com \
    --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 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).