public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@gnu.org>
To: "Martin Liška" <mliska@suse.cz>
Cc: Andreas Schwab <schwab@linux-m68k.org>,
	gcc-patches@gcc.gnu.org, Joseph Myers <joseph@codesourcery.com>
Subject: Re: [PATCH v2] Support --disable-fixincludes.
Date: Wed, 25 May 2022 02:37:20 -0300	[thread overview]
Message-ID: <or4k1ei35b.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <b42b87b7-6ce9-c9a9-1dab-40926fcc5e41@suse.cz> ("Martin \=\?utf-8\?Q\?Li\=C5\=A1ka\=22's\?\= message of "Tue, 24 May 2022 14:05:35 +0200")

On May 24, 2022, Martin Liška <mliska@suse.cz> wrote:

> Allways install limits.h and syslimits.h header files
> to include folder.

typo: s/Allways/Always/

I'm a little worried about this bit, too.  limitx.h includes
"syslimits.h", mentioning it should be in the same directory.  Perhaps
it could be left in include-fixed?

The patch also changes syslimits.h from either the fixincluded file or
gsyslimits.h to use gsyslimits.h unconditionally, which seemed wrong at
first.

Now I see how these two hunks work together: syslimits.h will now always
#include_next <limits.h>, which will find it in include-fixed if it's
there, and system header files otherwise.  Nice!, but IMHO the commit
message could be a little more verbose on the extent of the change and
why that (is supposed to) work.


It also looks like install-mkheaders installs limits-related headers for
when fixincludes runs; we could probably skip the whole thing if
fixincludes is disabled, but I'm also worried about how the changes
above might impact post-install fixincludes: if that installs
gsyslimits.h et al in include-fixed while your changes moves it to
include, headers might end up in a confusing state.  I haven't worked
out whether that's safe, but there appears to be room for cleanups
there.

gcc/config/mips/t-sdemtk also places syslimits.h explicitly in include/
rather than include-fixed/, as part of disabling fixincludes, which is
good, but it could be cleaned up as well.

I don't see other config fragments that might require adjustments, so I
think the patch looks good; hopefully my worries are unjustified, and
the cleanups it enables could be


We still create the README file in there and install it, even with
fixincludes disabled and thus unavailable, don't we?  That README then
becomes misleading; we might be better off not installing it.


> When --disable-fixincludes is used, then no systen header files
> are fixed by the tools in fixincludes. Moreover, the fixincludes
> tools are not built any longer.

typo: s/systen/system/


Could you please check that a post-install mkheaders still has a
functional limits.h with these changes?  The patch is ok (with the typo
fixes) if so.  The cleanups it enables would be welcome as separate
patches ;-)

Thanks!

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

  reply	other threads:[~2022-05-25  5:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-09  9:03 [PATCH] configure: add --disable-fix-includes Martin Liška
2022-05-09  9:31 ` Andreas Schwab
2022-05-09 21:14 ` Joseph Myers
2022-05-11 10:55   ` Martin Liška
2022-05-11 11:00     ` Rainer Orth
2022-05-11 11:15       ` Martin Liška
2022-05-11 11:31         ` Rainer Orth
2022-05-11 11:58           ` Martin Liška
2022-05-11 12:48             ` Andreas Schwab
2022-05-11 14:50               ` Martin Liška
2022-05-20 12:42                 ` Alexandre Oliva
2022-05-24 12:05                   ` [PATCH v2] Support --disable-fixincludes Martin Liška
2022-05-25  5:37                     ` Alexandre Oliva [this message]
2022-07-08 11:14                       ` Martin Liška
2022-07-09 16:11                         ` Jeff Law
2022-08-31  4:30                           ` Xi Ruoyao
2022-08-31  4:30                             ` Xi Ruoyao
2022-08-31 15:25                             ` Alexandre Oliva

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=or4k1ei35b.fsf@lxoliva.fsfla.org \
    --to=oliva@gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=mliska@suse.cz \
    --cc=schwab@linux-m68k.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.
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).