From: Michael Olbrich <m.olbrich@pengutronix.de>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] [PATCH] libptxdist: explicitly use sed to run migrate_*
Date: Fri, 14 Oct 2011 16:04:34 +0200 [thread overview]
Message-ID: <20111014140434.GE4886@pengutronix.de> (raw)
In-Reply-To: <8d386ec882c49464e95a77a4f92dc68b@biessmann.de>
Hi,
On Tue, Oct 11, 2011 at 12:16:09PM +0200, andreas@biessmann.de wrote:
> On Mon, 10 Oct 2011 18:04:56 +0200, Michael Olbrich wrote:
> >this fixes migrate on systems where sed is not in /bin/ (e.g. OS X).
> >
> >Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
> >---
> >
> >Hi,
> >
> >what about this? It's less invasive than using autoconf.
>
> Well, your solution fixes my problem with sed in shebang.
> But how about wrong sed in path? Or some other problems mentioned
> previously ([1], [2]).
>
> I see two solutions here:
> a) fix the surrounding/environment to match always the needs of
> ptxdist
> b) fix ptxdist to use specific environment
>
> a) seems easy to the ptxdist developers cause everyone using ptxdist
> needs
> to take care about his environment. That would include setting
> special PATH,
> write wrapper scripts or even forking ptxdist [1]. That could be really
> frustrating and scare off some users.
>
> b) seems easy to the users of pxdist, cause the configure/build/install
> of ptxdist takes care about correct versions of tools.
>
> I tend to vote for b) here. We do not want to scare off users but we
> do want a
> reliable, repeatable build process with easy to use interface.
> We even do it like this currently (e.g. 'configure
> --with-python=...'). But the
> tools found by configure are not taken into account when using
> ptxdist [2].
>
> Another solution compared to yours and my 'PATCH v2' could be some
> configuration-file
> which is written in installation phase and provide the environment
> for ptxdist.
> This could have another benefit, we can easily change the
> configuration for ptxdist
> at run-time without modifying a lot of installed scripts. I imagine ...
>
> ---8<---
> ~# ptxdist PTX_PYTHON=/whereever/i/installed/my/cool/python go
> --->8---
>
> So another poll here ;). We have
>
> a) the full autotools pre-processing of several scripts/rules ...
> files
> ('PATCH v2' solution)
> b) some (tbd) configuration file which could be sourced by ptxdist
> and provide
> the environment for all the scripts/make-file snippets a.s.o
> c) your solution (fix for sed with wrong path in sheebang)
>
> I would like to force a discussion now cause I have a bunch of
> patches on stack
> using the same approach as a) to fix the chmod problem mentioned in
> [1] and [3]. It
> would be great if we could get some conclusion soon so I could
> prepare my patchset.
I've been thinking about this for some time. I don't like preprocessing a
lot of files, because that makes developing ptxdist a pain. What I've
considered, but not implemented (no time so far) is the following:
create scripts/ptxdist_tools.sh.in that is preprocessed with autoconf the
stuff like this:
[...]
export PTXDIST_PYTHON="@PYTHON@"
export PTXDIST_SED="@SED@"
[...]
I think it should be sourced right before scripts/ptxdist_vars.sh.
Then use "${PTXDIST_PYTHON}", "${PTXDIST_SED}" everywhere. This way we get
the tools detected by configure without preprocessing a lot of files. Do
you think this can handle all the Problems you have?
However, making sure everything is using the correct tools will not be
easy. Replacing the calls in ptxdist is easy, but there are many packages
that call these tools directly, so they must be patched.
So far I've not had the time to even start this, but I'd be happy to apply
such patches.
I'll apply my patch for now. We can change 'sed' to '${PTXDIST_SED}' again
later.
Hmmm, I just had another idea: How about fixing the environment in ptxdist:
mkdir <TMP_BIN>/
ln -s @PYTHON@ <TMP_BIN>/python
ln -s @SED@ <TMP_BIN>/sed
[...]
export PATH=<TMP_BIN>:$PATH
[...]
just do this as early as possible in ptxdist and PATH will provide the
correct tools. Do you think that could work?
> There is one other point for me that would prefer the a) solution.
> We (sh|c)ould use
> more of the autotools foo to have a cleaner install directory (e.g.
> why installing all
> the files necessary to build the kconfig tools?).
Because it's easier and doesn't hurt? :-) Send patches...
Regards,
Michael
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
ptxdist mailing list
ptxdist@pengutronix.de
next prev parent reply other threads:[~2011-10-14 14:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-30 7:33 [ptxdist] [PATCH] scripts/migrate: use env to find sed Andreas Bießmann
2011-10-04 13:26 ` Michael Olbrich
2011-10-05 16:54 ` [ptxdist] [PATCH v2] scripts/migrate: use autotools to insert working sed Andreas Bießmann
2011-10-10 16:04 ` [ptxdist] [PATCH] libptxdist: explicitly use sed to run migrate_* Michael Olbrich
2011-10-11 10:16 ` andreas
2011-10-14 14:04 ` Michael Olbrich [this message]
2011-10-14 15:03 ` Bernhard Walle
2011-10-17 7:06 ` Andreas Bießmann
2011-10-17 10:45 ` Bernhard Walle
2011-10-17 12:53 ` Michael Olbrich
2011-10-17 6:54 ` Andreas Bießmann
2011-10-17 7:10 ` Andreas Bießmann
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=20111014140434.GE4886@pengutronix.de \
--to=m.olbrich@pengutronix.de \
--cc=ptxdist@pengutronix.de \
/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