From: Crystal Wood <crwood@redhat.com>
To: Clark Williams <williams@redhat.com>
Cc: Derek Barbosa <debarbos@redhat.com>,
clrkwllms@kernel.org, linux-rt-users@vger.kernel.org,
wander@redhat.com
Subject: Re: [PATCH 2/3] Makefile: Add support for legacy kernels
Date: Mon, 20 Oct 2025 11:48:16 -0500 [thread overview]
Message-ID: <84f6f9f25d0ecc7884e6a3f3f87c03f651545d27.camel@redhat.com> (raw)
In-Reply-To: <CAMLffL_a2-RkOJg8kXPZSKhzenu9aPDs4SBz-F97y9-wa_oHHQ@mail.gmail.com>
On Fri, 2025-10-17 at 13:01 +0000, Clark Williams wrote:
> On Tue, Oct 7, 2025 at 6:51 PM Crystal Wood <crwood@redhat.com> wrote:
> >
> > Speaking of SOPTS, is this tool intended to be Red Hat specific
> > (and require redhat-rpm-config even if no RPM building is intended)?
> >
> >
>
> No, I really don't like that we have it there in the main Makefile.
> Unfortunately we can't push it to the packaging phase since it
> affects things generated at compilation time.
>
> Perhaps we need to have a Makefile variable that identifies a
> "distro" and triggers inclusion of a Makefile.<distro> that modifies
> the appropriate flags? I know it's ugly but I'd like to give other
> folks (suse, cannonical, etc) a way to tweak the build. We could
> default the variable to "redhat" and have a block that includes
> Makefile.redhat to modify the CFLAGS appropriately.
Why can't the specfile build phase pass in the cflags it wants to add
(after fixing the makefile so that it appends to cflags rather than
replacing it)?
Ideally upstream shouldn't have to know about specific distros at all...
-Crystal
next prev parent reply other threads:[~2025-10-20 16:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-02 20:55 [PATCH 0/3] stalld: Improve legacy kernel support and unify sched_debug parsing Derek Barbosa
2025-10-02 20:55 ` [PATCH 1/3] sched_debug: Unify parsing methods for task_info Derek Barbosa
2025-10-02 20:55 ` [PATCH 2/3] Makefile: Add support for legacy kernels Derek Barbosa
2025-10-07 16:43 ` Clark Williams
2025-10-07 18:50 ` Crystal Wood
2025-10-08 13:07 ` Derek Barbosa
2025-10-08 16:50 ` Crystal Wood
2025-10-08 18:41 ` Derek Barbosa
2025-10-08 21:38 ` Crystal Wood
2025-10-08 23:52 ` Derek Barbosa
2025-10-10 4:07 ` Crystal Wood
2025-10-17 13:16 ` Clark Williams
2025-10-20 16:54 ` Crystal Wood
2025-10-20 18:18 ` Derek Barbosa
2025-10-17 13:20 ` Clark Williams
[not found] ` <CAMLffL_a2-RkOJg8kXPZSKhzenu9aPDs4SBz-F97y9-wa_oHHQ@mail.gmail.com>
2025-10-20 16:48 ` Crystal Wood [this message]
2025-10-21 13:04 ` Clark Williams
2025-10-02 20:55 ` [PATCH 3/3] scripts: fix run-local if bashism Derek Barbosa
2025-10-07 16:42 ` Clark Williams
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=84f6f9f25d0ecc7884e6a3f3f87c03f651545d27.camel@redhat.com \
--to=crwood@redhat.com \
--cc=clrkwllms@kernel.org \
--cc=debarbos@redhat.com \
--cc=linux-rt-users@vger.kernel.org \
--cc=wander@redhat.com \
--cc=williams@redhat.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.
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 NNTP newsgroup(s).