From: Steven Rostedt <rostedt@goodmis.org>
To: Vladislav Valtchev <vladislav.valtchev@gmail.com>
Cc: y.karadz@gmail.com, linux-trace-devel@vger.kernel.org
Subject: Re: [RFC PATCH v3 9/9] trace-cmd: Move GUI files in kernel-shark/
Date: Wed, 13 Dec 2017 10:51:10 -0500 [thread overview]
Message-ID: <20171213105110.21039649@gandalf.local.home> (raw)
In-Reply-To: <1513173046.2565.59.camel@gmail.com>
On Wed, 13 Dec 2017 15:50:46 +0200
Vladislav Valtchev <vladislav.valtchev@gmail.com> wrote:
> I meant "keeping this might be a problem".
> What I had in mind was that in the best case, with the hack in case
> the parent Makefile changes (adding config_includes and config flags),
> we'll link useless libraries. In the worst case, different versions of the same
> library might be used and that will cause and kind of strange build failures.
>
> But, I think keeping the hack in that patch makes sense, since the concept of
> config_includes and config_flags is fading away in the parent Makefile.
> In the next patches of the series also the trace-cmd application will have a separate
> directory and Makefile, so I could remove those variables from the parent Makefile.
> It seems fine to me to assume that only the Makefiles of the specific applications can
> really add config_flags (system libraries). The top-level Makefile should only orchestrate
> the others.
>
>
> Makes sense?
Sure.
-- Steve
next prev parent reply other threads:[~2017-12-13 15:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20171212162534.31144-1-vladislav.valtchev@gmail.com>
[not found] ` <20171212162534.31144-5-vladislav.valtchev@gmail.com>
[not found] ` <20171212190037.53710fa2@gandalf.local.home>
[not found] ` <1513171955.2565.42.camel@gmail.com>
2017-12-13 15:47 ` [RFC PATCH v3 4/9] trace-cmd: Extract part of Makefile in utils.mk Steven Rostedt
2017-12-18 15:29 ` Vladislav Valtchev
[not found] ` <20171212162534.31144-6-vladislav.valtchev@gmail.com>
[not found] ` <20171212192116.5e99d9aa@gandalf.local.home>
[not found] ` <1513166659.2565.37.camel@gmail.com>
2017-12-13 15:49 ` [RFC PATCH v3 5/9] trace-cmd: Move libparsevent *.c files in lib/pevent Steven Rostedt
2017-12-18 15:34 ` Vladislav Valtchev
2017-12-18 18:02 ` Steven Rostedt
[not found] ` <20171212162534.31144-10-vladislav.valtchev@gmail.com>
[not found] ` <20171212192911.0cd6aa14@gandalf.local.home>
[not found] ` <1513173046.2565.59.camel@gmail.com>
2017-12-13 15:51 ` Steven Rostedt [this message]
[not found] ` <20171212193004.05efce2e@gandalf.local.home>
[not found] ` <1513173368.2565.64.camel@gmail.com>
2017-12-13 15:53 ` [RFC PATCH v3 0/9] trace-cmd: restructure of the source tree [incomplete] Steven Rostedt
2017-12-18 15:35 ` Vladislav Valtchev
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=20171213105110.21039649@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=linux-trace-devel@vger.kernel.org \
--cc=vladislav.valtchev@gmail.com \
--cc=y.karadz@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.
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).