public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Arsen Arsenović" <arsen@aarsen.me>
To: Jonathan Wakely <jwakely@redhat.com>
Cc: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org
Subject: Re: [PATCH 1/2] libstdc++: Implement more maintainable <version> header
Date: Mon, 07 Aug 2023 19:22:50 +0200	[thread overview]
Message-ID: <86o7jivjs8.fsf@aarsen.me> (raw)
In-Reply-To: <CACb0b4nUD-eGzr1GfxEfjBd9Y0QWw7_W+UP5HK1eTG0dNeqjvQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1855 bytes --]


Jonathan Wakely <jwakely@redhat.com> writes:
> [...snip...]
> It looks like this will regenerate the bits/version.h file if it's older
> than the definitions or the autogen template, right?
>
> Generally we don't want to touch anything in the source tree as part of a
> normal build. It's OK to do that when configured with
> --enable-maintainer-mode (which nobody working on libstdc++ actually uses,
> because it causes problems IME) or via a dedicated target which is not
> built by default (e.g. doc/Makefile.am has the doc-html-docbook-regenerate
> target, which is isn't a prereq of any other targets so it's only run if
> you explicitly request it).
>
> The problem with modifying the source tree as part of a normal build is
> that it might be on read-only media, and so the build will fail if this
> target can't be updated. We would also want to add the version.h header to
> the contrib/gcc_update script that updates the timestamps of generated
> files, so that they are always newer than their prereqs.
>
> Maybe the best option here is to assume that version.h is always up to
> date, and add a custom target to regen it manually, which we can run after
> editing the .def or .tpl files. What do you think?

Ah, I wasn't aware of this concern.  I'll make it a phony target, yeah.

> My only other concern with this patch is that I don't speak lisp so the
> Guile code in version.tpl is opaque and unmaintainable for me. That is
> fixable though.

The algorithm the code implements is quite simple, it just verifies that
the three numeric fields associated with each FTM are in a non-ascending
order (which ensures that the most broad option comes last in the
#if/#elif chain).  It's a sanity check that's caught a couple of
transcription errors I made during the initial conversion.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

  reply	other threads:[~2023-08-07 17:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-29 10:16 [PATCH 0/2] Unify and deduplicate FTM code Arsen Arsenović
2023-04-29 10:16 ` [PATCH 1/2] libstdc++: Implement more maintainable <version> header Arsen Arsenović
2023-06-01 20:06   ` Jonathan Wakely
2023-08-07 17:22     ` Arsen Arsenović [this message]
2023-04-29 10:16 ` [PATCH 2/2] libstdc++: Replace all manual FTM definitions and use Arsen Arsenović
2023-06-01 20:30   ` Jonathan Wakely
2023-08-07 17:34     ` Arsen Arsenović
2023-08-07 17:38     ` Arsen Arsenović
2023-05-08 23:08 ` Ping: [PATCH 0/2] Unify and deduplicate FTM code Arsen Arsenović

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=86o7jivjs8.fsf@aarsen.me \
    --to=arsen@aarsen.me \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jwakely@redhat.com \
    --cc=libstdc++@gcc.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.
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).