Re: [ptxdist] [PATCH] libptxdist: explicitly use sed to run migrate_*

2011-10-17 Thread Andreas Bießmann

Dear Michael,

On Fri, 14 Oct 2011 16:04:34 +0200, Michael Olbrich wrote:

Hi,

On Tue, Oct 11, 2011 at 12:16:09PM +0200, andr...@biessmann.de wrote:

On Mon, 10 Oct 2011 18:04:56 +0200, Michael Olbrich wrote:


snip

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?


Yes it will ...

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.


But I also see your objections and therefore favour your second 
suggestion.


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.


That is ok for me, at least it will fix my problem with migration 
scripts.


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?


Yes I think so. It should be done while installing the 
scripts/rules/a.s.o and 'export PATH=TMP_BIN:$PATH' should be added to 
ptxdist_vars.sh.
So how about naming TMP_BIN $PTXDIST_BIN and placing it at 
${PTXDIST_TOPDIR}/bin? If that is ok I will provide patches to get 
ptxdist working on OS X these days.



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...


Will do.

best regards

Andreas Bießmann


--
ptxdist mailing list
ptxdist@pengutronix.de


Re: [ptxdist] [PATCH] libptxdist: explicitly use sed to run migrate_*

2011-10-17 Thread Andreas Bießmann

On Mon, 17 Oct 2011 08:54:04 +0200, Andreas Bießmann wrote:

Dear Michael,

On Fri, 14 Oct 2011 16:04:34 +0200, Michael Olbrich wrote:

Hi,

On Tue, Oct 11, 2011 at 12:16:09PM +0200, andr...@biessmann.de 
wrote:

On Mon, 10 Oct 2011 18:04:56 +0200, Michael Olbrich wrote:


snip


So how about naming TMP_BIN $PTXDIST_BIN and placing it at
${PTXDIST_TOPDIR}/bin? If that is ok I will provide patches to get
ptxdist working on OS X these days.


Ok, PTXDIST_BIN is already assigned (should really check before sending 
...). So how about PTSXIDST_TMPBIN/_BINDIR/... or renaming the 
PTXDIST_BIN in url_check plugins to some other name.


best regards

Andreas Bießmann

--
ptxdist mailing list
ptxdist@pengutronix.de


Re: [ptxdist] [PATCH] libptxdist: explicitly use sed to run migrate_*

2011-10-17 Thread Andreas Bießmann

Dear Bernhard,

On Fri, 14 Oct 2011 17:03:43 +0200, Bernhard Walle wrote:

Hi,

* Michael Olbrich m.olbr...@pengutronix.de [2011-10-14 16:04]:
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?


That's what I'm doing in the Arch Linux ptxdist package [1]. Arch 
Linux

has /usr/bin/python pointing to /usr/bin/python3 instead of python2.
There's a configure flag for ptxdist and Python, but that doesn't 
work.


I sent a patch [2], but even that patch doesn't fix everything 
(there's
still some ipkg problem). Because I was too lazy I changed it that 
way

(modifying PATH).

I'm doing

- 8 
export PATH=$(dirname $(readlink -f $0)):$PATH
- 8 

which inclues /usr/lib/ptxdist-2011.xx.y/bin into $PATH and that 
works.


Seems to me the best solution for our problem. I think the current 
discussion is leading to some PTXDIST_BINDIR directory with links to the 
respective tools.



It's not really nice, but I think it's better than patching lots of
tools. And having scripts as executable programs is IMO still better
than having to call the interpreter manually (which is necessary with
your $PTXDIST_SED approach.


But how should we handle a script's sheebang? If we require the 
scripts/migrate tools to be executable scripts we need to preprocess the 
scripts to adopt the sheebang to e.g. $PTXDIST_BINDIR. I think it is 
much more portable to have the shell scripts kall the interpreter with 
the respective configuration, e.g. $PTXDIST_BINDIR/sed -f 
scripts/migrate/migrate_platform.



Regards,
Bernhard

[1] http://aur.archlinux.org/packages.php?ID=49649
[2] http://www.mail-archive.com/ptxdist@pengutronix.de/msg04264.html


best regards

Andreas Bießmann

--
ptxdist mailing list
ptxdist@pengutronix.de


Re: [ptxdist] [PATCH] libptxdist: explicitly use sed to run migrate_*

2011-10-17 Thread Bernhard Walle
* Andreas Bießmann andr...@biessmann.de [2011-10-17 09:06]:
 
 It's not really nice, but I think it's better than patching lots of
 tools. And having scripts as executable programs is IMO still better
 than having to call the interpreter manually (which is necessary with
 your $PTXDIST_SED approach.
 
 But how should we handle a script's sheebang? If we require the
 scripts/migrate tools to be executable scripts we need to preprocess
 the scripts to adopt the sheebang to e.g. $PTXDIST_BINDIR. I think
 it is much more portable to have the shell scripts kall the
 interpreter with the respective configuration, e.g.
 $PTXDIST_BINDIR/sed -f scripts/migrate/migrate_platform.

sed is the only exception I know that requires an argument.
#!/usr/bin/env perl, #!/usr/bin/env python, #!/usr/bin/env ruby works.


Regards,
Bernhard

-- 
ptxdist mailing list
ptxdist@pengutronix.de


Re: [ptxdist] [PATCH] libptxdist: explicitly use sed to run migrate_*

2011-10-14 Thread Michael Olbrich
Hi,

On Tue, Oct 11, 2011 at 12:16:09PM +0200, andr...@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.olbr...@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- |

-- 
ptxdist mailing list
ptxdist@pengutronix.de


Re: [ptxdist] [PATCH] libptxdist: explicitly use sed to run migrate_*

2011-10-14 Thread Bernhard Walle
Hi,

* Michael Olbrich m.olbr...@pengutronix.de [2011-10-14 16:04]:
 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?

That's what I'm doing in the Arch Linux ptxdist package [1]. Arch Linux
has /usr/bin/python pointing to /usr/bin/python3 instead of python2.
There's a configure flag for ptxdist and Python, but that doesn't work.

I sent a patch [2], but even that patch doesn't fix everything (there's
still some ipkg problem). Because I was too lazy I changed it that way
(modifying PATH).

I'm doing 

- 8 
export PATH=$(dirname $(readlink -f $0)):$PATH
- 8 

which inclues /usr/lib/ptxdist-2011.xx.y/bin into $PATH and that works.
It's not really nice, but I think it's better than patching lots of
tools. And having scripts as executable programs is IMO still better
than having to call the interpreter manually (which is necessary with
your $PTXDIST_SED approach.


Regards,
Bernhard

[1] http://aur.archlinux.org/packages.php?ID=49649
[2] http://www.mail-archive.com/ptxdist@pengutronix.de/msg04264.html

-- 
ptxdist mailing list
ptxdist@pengutronix.de


Re: [ptxdist] [PATCH] libptxdist: explicitly use sed to run migrate_*

2011-10-11 Thread andreas

Dear Michael,

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.olbr...@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.


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?).

best regards

Andreas Bießmann

[1] http://www.mail-archive.com/ptxdist@pengutronix.de/msg01899.html
[2] http://www.mail-archive.com/ptxdist@pengutronix.de/msg04264.html
[3] 
http://git.pengutronix.de/?p=mkl/ptxdist.git;a=commitdiff;h=f6479b400b402815db9c74980557a492eaf26fe3


--
ptxdist mailing list
ptxdist@pengutronix.de