[9fans] Two suggestions for ape (was: egrep for Plan9)

[9fans] Two suggestions for ape (was: egrep for Plan9)

[Dimitry Golubovsky]

Great, thanks Russ.

I have two suggestions for ape minor additions arising from my recent
attempts to run configure scripts on Plan9

1. Add this script (suggested by Russ) as /rc/bin/ape/egrep

#!/bin/rc
if(~ $1 -E) shift
exec grep $*

2. Make ls accept -i option (if inode numbers do not exists in Plan9
then it could print some numeric hash of file path, whatever)

These things are needed by autoconf. For the former, the script above
worked fine as egrep. For the latter, autoconf supplies code using "ls
-di" when checking the current directory. I had to redefine the
corresponding function locally to get around this. Looks like these
things are hardwired in the autoconf macro library.

Thanks.

--
Dimitry Golubovsky

Anywhere on the Web

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[Jason Catena]

Dimitry wrote:
> I have two suggestions for ape minor additions arising from my recent
> attempts to run configure scripts on Plan9
>
> These things are needed by autoconf.
>
> Looks like these
> things are hardwired in the autoconf macro library.

Since autoconf should deal with "any" unixy environment in which it
finds itself (that's supposed to be what it does for a living),
shouldn't it be patched to deal with a lack of POSIX grep's -E and
POSIX ls' -i?  In general, as a porting tool, it should not make
demands on the host system for the presence of egrep, or options are
defined by GNU tools (or even POSIX).  Making such demands places
arbitrary limits on how portable the gnu tools are, or any tools using
autoconf.  (Given the FSF's philosophy, this may be intentional.)

POSIX-ls has 23 options to Plan9-ls' 12.  I can't imagine that we'd
add in all the remaining options of ls just because some program or
another uses them.

egrep has 42 options to POSIX-grep's 11 options to Plan9-grep's
different 11.  I can't imagine that we'd change around the meaning of
the 11 options to suit POSIX, let alone add in the extra ones of
egrep.

Take all this with a grain of salt, because I don't speak for any
distribution. :)

> Dimitry Golubovsky

Jason Catena

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[Charles Forsyth]

it's /rc/bin/ape/ls that would change, not Plan 9's ls-proper.

what does autoconf do with the `inode number'?

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[W B Hacker]

Charles Forsyth wrote:
> it's /rc/bin/ape/ls that would change, not Plan 9's ls-proper.
>
> what does autoconf do with the `inode number'?
>
>

Haven't you heard of the elephant that escaped from a traveling circus and
wandered into the vegetable garden of a lady who had never seen an elephant in
her life? Not even in pictures.

She called the local sheriff and reported a great grey-skinned beast was pulling
up all her carrots with its ..tail.

Puzzled sheriff asked what it was DOING with the carrots thereafter...

She said, "Sheriff, you wouldn't believe me if I told you.."

So, too, autoconf and those inode numbers...

;-)

Bill

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[Federico G. Benavento]

I have no idea, but I know that removing the -i switch from configure
gets it going,
so just ignoring it should be good enough

On Fri, Oct 23, 2009 at 12:12 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
> it's /rc/bin/ape/ls that would change, not Plan 9's ls-proper.
>
> what does autoconf do with the `inode number'?
>
>



--
Federico G. Benavento

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[Dmitry Golubovsky]

Charles,

On Oct 23, 10:40 am, fors...@terzarima.net (Charles Forsyth) wrote:
> it's /rc/bin/ape/ls that would change, not Plan 9's ls-proper.

Of course ape's one. As well as I am proposing to add egrep to ape's
tree not Plan9's native tree.

> what does autoconf do with the `inode number'?

In fact, nothing is done with inode number.

Autoconf generates code to obtain the current directory which involves
ls -di.

Here is the macro in /usr/share/autoconf/autoconf/general.m4 that
causes the problem:

# _AC_INIT_DIRCHECK
# -----------------
# Set ac_pwd, and sanity-check it and the source and installation
directories.
#
# (This macro is AC_REQUIREd by _AC_INIT_SRCDIR, so it has to be
AC_DEFUNed.)
#
AC_DEFUN([_AC_INIT_DIRCHECK],
[m4_divert_push([PARSE_ARGS])dnl

ac_pwd=`pwd` && test -n "$ac_pwd" &&
ac_ls_di=`ls -di .` &&
ac_pwd_ls_di=`cd "$ac_pwd" && ls -di .` ||
  AC_MSG_ERROR([Working directory cannot be determined])
test "X$ac_ls_di" = "X$ac_pwd_ls_di" ||
  AC_MSG_ERROR([pwd does not report name of working directory])

m4_divert_pop([PARSE_ARGS])dnl
])# _AC_INIT_DIRCHECK

I have redefined the macro locally to use only ls -d, it works.

the problem is, as can be seen: ls -di is hardcoded in assumption that
every ls understands it.

I use autoconf 2.63. This macro might be different in older versions.
I am currently looking at configure in the same project archive
created with 2.59 (in 2007), I cannot see traces of this macro there,
although configure.ac was likely the same.

This test (as well as egrep test) is something autoconf uses for
internal purposes.

Jason: I understand your reasoning. However if two small fixes would
unblock execution of many projects' configure on Plan9 IMHO they are
worth making; they won't break anything.

Thanks.

Dmitry

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[Jason Catena]

> Jason: I understand your reasoning. However if two small fixes would
> unblock execution of many projects' configure on Plan9 IMHO they are
> worth making; they won't break anything.

I wasn't going to comment again on this, since it's ape's tools, not
the plan9 versions.  I was obviously mistaken in assuming that you
suggested changing plan9's version.

I still personally feel that for plan9 to mean something, additional
options and tools should be considered on their own merits and because
they fit the plan9 philosophy, not because some random tool uses them
and ignores them.  From what's been described here autoconf should not
have the expectation that it gets -i, just to ignore it.  For ape
that's fine, but from what I've had rejected I believe the core of
plan9 is held to a higher standard.

> Dmitry

Jason Catena

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[Tim Newsham]

> Jason: I understand your reasoning. However if two small fixes would
> unblock execution of many projects' configure on Plan9 IMHO they are
> worth making; they won't break anything.

What if you just made a command "gnuconfig" which rewrote the
configure script, fixing the minor defects, and ran the result?
Or bound in a dummy "ls" and "egrep" before executing the real
configure script?
Lets keep the infection contained.

> Thanks.
> Dmitry

Tim Newsham
http://www.thenewsh.com/~newsham/

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[Jason Catena]

> What if you just made a command "gnuconfig" which rewrote the
> configure script, fixing the minor defects, and ran the result?

I wrote an rc script (vary
http://codereview.appspot.com/117087/diff/1/2) which generally applies
a sam script to a file (via ssam
http://codereview.appspot.com/95076/diff/9038/10015) and runs the
result.  For configure, it would be called something like

    vary -x plan9port.sam configure --configure-opt

which would create a new variation of the configure script, called
configure.plan9port, and run it.

> Tim Newsham

Jason Catena

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[Federico G. Benavento]

http://plan9.bell-labs.com/sources/contrib/fgb/rc/config

hacks configure and mostly gets it going

for egrep and fgrep
aux/stub /bin/egrep
bind /bin/grep /bin/egrep

On Fri, Oct 23, 2009 at 4:18 PM, Tim Newsham <newsham@lava.net> wrote:
>> Jason: I understand your reasoning. However if two small fixes would
>> unblock execution of many projects' configure on Plan9 IMHO they are
>> worth making; they won't break anything.
>
> What if you just made a command "gnuconfig" which rewrote the
> configure script, fixing the minor defects, and ran the result?
> Or bound in a dummy "ls" and "egrep" before executing the real
> configure script?
> Lets keep the infection contained.
>
>> Thanks.
>> Dmitry
>
> Tim Newsham
> http://www.thenewsh.com/~newsham/
>
>



--
Federico G. Benavento

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[Dmitry Golubovsky]

Tim,

On Oct 23, 2:23 pm, news...@lava.net (Tim Newsham) wrote:

> What if you just made a command "gnuconfig" which rewrote the
> configure script, fixing the minor defects, and ran the result?
> Or bound in a dummy "ls" and "egrep" before executing the real
> configure script?
> Lets keep the infection contained.

If I need to fix this for my project only, I have already done that.

The problem is, everyone who generates configure by this version (or
some range of versions) of autoconf would run into this because this
is inserted in the configure's initialization code without any feature
tests requested by configure.ac

Since the purpose of ape is to emulate the environment configure is
expected to run in, and such mismatch has been found, it migh be
easier to fix ape than to convince maintaners of autoconf to fix on
their side...

Dmitry.

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[hiro]

> Since the purpose of ape is to emulate the environment configure is
> expected to run in, and such mismatch has been found, it migh be
> easier to fix ape than to convince maintaners of autoconf to fix on
> their side...

Why are you so sure they wouldn't fix it? Have you or has anybody you
know tried something like this already?

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[Dmitry Golubovsky]

On Oct 26, 9:21 am, 23h...@googlemail.com (hiro) wrote:
> > Since the purpose of ape is to emulate the environment configure is
> > expected to run in, and such mismatch has been found, it migh be
> > easier to fix ape than to convince maintaners of autoconf to fix on
> > their side...
>
> Why are you so sure they wouldn't fix it? Have you or has anybody you
> know tried something like this already?

Because even if they fix it in the current (or perhaps the nearest
future) version (in repos now) of autoconf this would not apply
retroactively to previous/current versions everyone has.

Besides, one thing (very long regexp to match all ASCII letters and
numbers in a CPP directive - see the thread on awk incompatibility) is
done on purpose: they specifically wanted to avoid character ranges
(perhaps wrt some locales where a-z range might also include letters
with diacritics, but this is only my guess). Regexp buffer length
limitation in Plan9 awk may be more fundamental problem.

Well, these problems arise only if one wants to have a port for Plan9
share the sources with upstream (hence to have common configure
scripts, Makefiles, tools, etc.)

If a fork-style port for Plan9 is considered then of course everything
may be adjusted properly (like configure is not needed at all because
there is only one
configuration, etc.).

Thanks.

Re: [9fans] Two suggestions for ape

[W B Hacker]

Dmitry Golubovsky wrote:
> On Oct 26, 9:21Â am, 23h...@googlemail.com (hiro) wrote:
>>> Since the purpose of ape is to emulate the environment configure is
>>> expected to run in, and such mismatch has been found, it migh be
>>> easier to fix ape than to convince maintaners of autoconf to fix on
>>> their side...
>> Why are you so sure they wouldn't fix it? Have you or has anybody you
>> know tried something like this already?
>
> Because even if they fix it in the current (or perhaps the nearest
> future) version (in repos now) of autoconf this would not apply
> retroactively to previous/current versions everyone has.
>
> Besides, one thing (very long regexp to match all ASCII letters and
> numbers in a CPP directive - see the thread on awk incompatibility) is
> done on purpose: they specifically wanted to avoid character ranges
> (perhaps wrt some locales where a-z range might also include letters
> with diacritics, but this is only my guess). Regexp buffer length
> limitation in Plan9 awk may be more fundamental problem.
>
> Well, these problems arise only if one wants to have a port for Plan9
> share the sources with upstream (hence to have common configure
> scripts, Makefiles, tools, etc.)
>
> If a fork-style port for Plan9 is considered then of course everything
> may be adjusted properly (like configure is not needed at all because
> there is only one
> configuration, etc.).
>
> Thanks.
>
>

A problem is being made without looking at proven solutions.

NEITHER the 'upstream' port NOR Plan9 should be radically changed.

Why risk breakage or future problems in EITHER?

Nor is it necessary to 'fork' the build system.

Just provide Plan9-specific patch(es), and a line or two for the configure (or
directly into the Makefile) that checks for a Plan9 environment, makes the
relevant adjustments (dirtrees are important, too) and sucks in the appropriate
patch(es).

Look, for example, at any of a very large number of FreeBSD ports. Most carry a
small patch set added by the FreeBSD-specific port maintainer.

In this case, the needful stuff was offered earlier in the thread. It could be
used to alter the behaviour of awk - but only for the life of that build
process, needing no change to the original sources OR Plan9's 'normal'
behaviour.

I cite FeeBSD, if for no other reason than their huge count of ports -  but
'awk' is hardly the only issue, and some form of that need is also found w/r
AIX, Solaris, HP UX and several others - not to mention Linux and BSD 'flavors'
as build targets, so it is hardly new ground.

CAVEAT: Expect some need for education upstream. Not everyone is aware that
Plan9 is still among the living.

;-)

JM2CW

Bill

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[erik quanstrom]

> The problem is, everyone who generates configure by this version (or
> some range of versions) of autoconf would run into this because this
> is inserted in the configure's initialization code without any feature
> tests requested by configure.ac

lots of discussion of autoconf at the gsoc mentor's summit.
the general consensus is that getting autoconf to work correctly
just doesn't pay unless your os is really similar to linux and
there's no cross compiling going on.

i think it's interesting to note that the way p9p/9vx accomplish
portability doesn't result with very little platform-specific code
and build bits while remaining more  more flexable.  did i mention
that it's easy to understand as well?

- erik

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[Anthony Sorace]

// Since the purpose of ape is to emulate the environment
// configure is expected to run in...

false premise. the purpose of ape is to provide an ANSI/POSIX environment.
it's purpose is as much for outbound porting as inbound, and maintaining the
actual target is more important in that direction.

the purpose of *conf* is to match the environment it finds itself in. as such,
submitting modifications to that is clearly the correct long-term plan. you're
correct that modifications to *conf* won't help already-distributed packages,
but that seems like not a very good reason to give up the nicely specified
target for ape ("ANSI/POSIX Environment" being a lot easier to define
than "Whatever-Gnu-Assumes-This-Week Environment"). having something
else,
not ape, targeted at broader compatibility might also be useful (some people
have complained about ape's need for defining symbols to use non-ANSI
libraries, for example), but it's a different enough objective that it
ought to be
a different thing (GAPE?).

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[erik quanstrom]

> // Since the purpose of ape is to emulate the environment
> // configure is expected to run in...
>
> false premise. the purpose of ape is to provide an ANSI/POSIX environment.
> it's purpose is as much for outbound porting as inbound, and maintaining the
> actual target is more important in that direction.
>
> the purpose of *conf* is to match the environment it finds itself in. as such,
> submitting modifications to that is clearly the correct long-term plan. you're
> correct that modifications to *conf* won't help already-distributed packages,
> but that seems like not a very good reason to give up the nicely specified
> target for ape ("ANSI/POSIX Environment" being a lot easier to define
> than "Whatever-Gnu-Assumes-This-Week Environment"). having something
> else,
> not ape, targeted at broader compatibility might also be useful (some people
> have complained about ape's need for defining symbols to use non-ANSI
> libraries, for example), but it's a different enough objective that it
> ought to be
> a different thing (GAPE?).

there were a lot of wierd os people talking to a lot of package
maintainers at google this weekend.  the solution that made
sense to *BOTH* was to ditch autoconf and submit a platform
specific makefile.

it seems we find ourselves exactly in the situation we were in
in 1992.  the existing portability hacks don't work.  and when
they don't work they become counter productive.

- erik

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[ron minnich]

On Tue, Oct 27, 2009 at 9:16 AM, erik quanstrom <quanstro@coraid.com> wrote:

> there were a lot of wierd os people talking to a lot of package
> maintainers at google this weekend.  the solution that made
> sense to *BOTH* was to ditch autoconf and submit a platform
> specific makefile.

I'm impressed. What are the prospects of this happening. It is good
news if people decide to go that route.

ron

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[erik quanstrom]

> I'm impressed. What are the prospects of this happening. It is good
> news if people decide to go that route.
>

in certain cases, 100%.

there was also a bit of talk about os agnostic driver stubs.
i'm a little pessimestic about the chances for success there,
especially for oses that don't use the berkeley socket stuff.
but it's probablly something that's worth talking about.

- erik

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[tlaronde]

On Tue, Oct 27, 2009 at 12:37:58PM -0400, erik quanstrom wrote:
>
> there was also a bit of talk about os agnostic driver stubs.
> i'm a little pessimestic about the chances for success there,
> especially for oses that don't use the berkeley socket stuff.
> but it's probablly something that's worth talking about.

Wasn't there an "OS kit" or something like that with drivers derived
from Linux one's at some moment? Found this some years ago when I was
searching doc. about OSes---I seem to remember this was when looking for
Mach (!) documentation, so could be CMU.

--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[Tim Newsham]

> Wasn't there an "OS kit" or something like that with drivers derived
> from Linux one's at some moment? Found this some years ago when I was
> searching doc. about OSes---I seem to remember this was when looking for
> Mach (!) documentation, so could be CMU.

yes, utah (also did mach work) made oskit:
http://www.cs.utah.edu/flux/oskit/
the purpose of which was to borrow some of the hard parts to make
writing research OSes easier.

> Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
>                 http://www.kergis.com/

Tim Newsham
http://www.thenewsh.com/~newsham/

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[Francisco J Ballesteros]

the oskit was a great tool.
Only that if you wanted to use some component, in the end,
most of them had to be pulled into.

On Tue, Oct 27, 2009 at 10:43 PM, Tim Newsham <newsham@lava.net> wrote:
>> Wasn't there an "OS kit" or something like that with drivers derived
>> from Linux one's at some moment? Found this some years ago when I was
>> searching doc. about OSes---I seem to remember this was when looking for
>> Mach (!) documentation, so could be CMU.
>
> yes, utah (also did mach work) made oskit:
> http://www.cs.utah.edu/flux/oskit/
> the purpose of which was to borrow some of the hard parts to make
> writing research OSes easier.
>
>> Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
>>                http://www.kergis.com/
>
> Tim Newsham
> http://www.thenewsh.com/~newsham/
>
>

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[Dave Eckhardt]

> Wasn't there an "OS kit" or something like that with drivers
> derived from Linux one's at some moment?

University of Utah, "Flux OSkit".

Old OSkit is mostly BSD licensed (if you count the CMU Mach license
as a BSD license), but at some point somebody sprayed the GPL over
everything (somewhat reducing the utility of some CMU-derived code
for a project here at CMU, but I digress).

If you are looking for an approximation of the last non-GPL'd OSkit,
I think this is probably it:

  http://os.inf.tu-dresden.de/fiasco/download/fiasco-1.1-oskit.tar.bz2

Dave Eckhardt

Re: [9fans] Two suggestions for ape (was: egrep for Plan9)

[tlaronde]

On Tue, Oct 27, 2009 at 08:23:10PM -0400, Dave Eckhardt wrote:
>
> University of Utah, "Flux OSkit".
>
> Old OSkit is mostly BSD licensed (if you count the CMU Mach license
> as a BSD license), but at some point somebody sprayed the GPL over
> everything (somewhat reducing the utility of some CMU-derived code
> for a project here at CMU, but I digress).
>
> If you are looking for an approximation of the last non-GPL'd OSkit,
> I think this is probably it:
>
>   http://os.inf.tu-dresden.de/fiasco/download/fiasco-1.1-oskit.tar.bz2

Thanks to everyone for the pointers and the complementary informations
about the status. The idea seems logical at first and even rewarding for
hardware manufacturers (you can easily copy soft; cloning a device is
more difficult at home and certainly not cheaper...), since the more
OSes have drivers, the more customers can buy the devices. But since
there is a kind of OS dominating, there is a bias. And since, more and
more, even in "open" OSes, there are BLOBs...
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C