Discussion:
make
(too old to reply)
stephen Turner
2015-01-22 15:54:46 UTC
Permalink
so Gnu make isnt bad but it isnt that great either, I found what looks like
it might be a nice little make program but the depressing down side is it
uses a new language tcl. its so simple! I dont understand why stuff like
this doesnt catch on unless its not as good as they are making it out to
be?

http://wiki.tcl.tk/9293

on a plus side it sounds like tcl is easy to learn. albiet its not as
simple as just writing a shell script for a makefile


https://lkubuntu.wordpress.com/2013/01/09/shbuild-an-alternative-to-gnu-make-using-shell-scripts/

am i missing something or is gnu make the only Makefile processing make
program without adding additional dependencies like perl?
dmccunney
2015-01-22 16:15:32 UTC
Permalink
On Thu, Jan 22, 2015 at 10:54 AM, stephen Turner
Post by stephen Turner
so Gnu make isnt bad but it isnt that great either, I found what looks like
it might be a nice little make program but the depressing down side is it
uses a new language tcl. its so simple! I dont understand why stuff like
this doesnt catch on unless its not as good as they are making it out to be?
http://wiki.tcl.tk/9293
on a plus side it sounds like tcl is easy to learn. albiet its not as simple
as just writing a shell script for a makefile
Tcl is a scripting language created by John Ousterhout when he was a
Professor of Computer Science at UC. His students were developing a
network operating system called Amoeba. Dr. Ousterhout wrote Tcl to
be a glue language. Tk was added later as a means of providing
graphical widgets, and has been used in other efforts as well.

Tcl underlies Done Libes' Expect utility, which is just the thing if
you need to automate processes that are normally run interactively.

You could probably use Tcl to implement make functionality (though I'm
not aware of anyone who has), but that requires you to have Tcl
available. It's available for Linux, but not all distros include it
as a default.

I recommend Brent Welch's "Practical Programming in Tcl and Tk" from
Prentice Hall as the best Tcl book I'm aware of. For Expect, you want
Don Libes' "Exploring Expect" published by O'Reilly.
Post by stephen Turner
https://lkubuntu.wordpress.com/2013/01/09/shbuild-an-alternative-to-gnu-make-using-shell-scripts/
am i missing something or is gnu make the only Makefile processing make
program without adding additional dependencies like perl?
Another popular alternative is Scons (http://www.scons.org/), but
Scons requires Python.

Wikipedia has a list of build automation software -
http://en.wikipedia.org/wiki/List_of_build_automation_software
______
Dennis
https://plus.google.com/u/0/105128793974319004519
stephen Turner
2015-01-22 16:53:03 UTC
Permalink
Post by dmccunney
Post by stephen Turner
am i missing something or is gnu make the only Makefile processing make
program without adding additional dependencies like perl?
Another popular alternative is Scons (http://www.scons.org/), but
Scons requires Python.
Wikipedia has a list of build automation software -
http://en.wikipedia.org/wiki/List_of_build_automation_software
______
Dennis
https://plus.google.com/u/0/105128793974319004519
thanks Dennis, thats the thing i keep finding for replacements to make.
they involve other languages. im facinated with the tcl one because a guy
wrote what appears to be a one page (really small) tcl script for parsing
tcl make files. it almost makes me want to use tcl. I was hoping for a
simpler remake of make in c though, something like a clean up job with
possibly some feature extensions but makepp which was the best candidate i
found requires perl. Maybe i can learn c and rewrite make myself? I still
have a hard time reading C but maybe...

I just found a project "elf tool chain" is this a viable replacement for
binutils? Im definitely going to give it a shot today and see if anything
breaks just for fun!

http://sourceforge.net/projects/elftoolchain/

stephen
Rob Landley
2015-01-23 10:08:08 UTC
Permalink
Post by dmccunney
On Thu, Jan 22, 2015 at 10:54 AM, stephen Turner
Post by stephen Turner
so Gnu make isnt bad but it isnt that great either, I found what looks like
it might be a nice little make program but the depressing down side is it
uses a new language tcl. its so simple! I dont understand why stuff like
this doesnt catch on unless its not as good as they are making it out to be?
http://wiki.tcl.tk/9293
on a plus side it sounds like tcl is easy to learn. albiet its not as simple
as just writing a shell script for a makefile
Way back when I was looking at rewriting toybox in lua, but having to
cross compile a language runtime to a new architecture wasn't a huge
step up from having to cross compile a C binary.

I have a todo item to write a "make", either for toybox for for my
proposed qcc project (my old tcc fork + qemu's tcg Tiny Code Generator).
In either case, it's not until after 1.0.

I tried to build toybox under the bsd make in pcbsd, and... it did not
go well. Just getting kconfig (menuconfig) to build was enough of a
blocker I wandered off and did other things. My approach to gmake is
similar to my approach to bash: clone one that does enough of the same
stuff to migrate the existing users off, regardless of what subset may
be "standardized". If the standard isn't enough to support actual use
cases, then the standard is merely a frame of reference to diverge from
and from there you debug the use cases and add the things they need.
Post by dmccunney
Tcl is a scripting language created by John Ousterhout when he was a
Professor of Computer Science at UC. His students were developing a
network operating system called Amoeba. Dr. Ousterhout wrote Tcl to
be a glue language. Tk was added later as a means of providing
graphical widgets, and has been used in other efforts as well.
Tcl underlies Done Libes' Expect utility, which is just the thing if
you need to automate processes that are normally run interactively.
I've meant to write an "expect" in C for years as well, but I don't use
the existing expect enough to just knock off a version with the
semantics its existing users want.

To be honest when confronted with expect, I wrote my own version in
python because it was easier than learning anything about tcl. Since
then I've written shell and C versions, but I haven't tried to publish
them because I dunno how to use the existing tcl one. (I remember poking
at it for 15 minutes and being confused, and then writing a new one in
like 5. It's not that it's hard to learn, just that it really didn't
seem _worth_ it for what it was doing...)

(Yes, getting it to work in shell was fiddly: I had to use mkfifo.
There's almost certainly a better way but that's the one I got working
first. For years I've wanted a shell command called 'loop' that pipes
the output at the end of the command line back into the input at the
beginning. Maybe I'll put it in toysh.)

(Ok, "for years" turns out to be "for well over a decade":
http://osdir.com/ml/linux.busybox/2004-01/msg00048.html . Sheesh, why
don't people steal my ideas and _implement_ them more often, so I don't
have to?)

The basic functionality is trivial to do in toybox because I already
wrote the hard bits in lib/xwrap.c function xpopen_both(). Example
usages (through two different wrappers) are in mount.c to call losetup
and swapon. But it parses some sort of config file and then maybe needs
regex searches to match things? And does it extract data from its input
and process it to produce output, or something?

Again: a possible todo item after 1.0. Not because it's hard to write
but because I don't know what the command should _do_. Expect has a
command script that apparently you can embed tcl snippets into, or
something? (I should go look at it, but it's waaaaaay down the todo list.)
Post by dmccunney
You could probably use Tcl to implement make functionality (though I'm
not aware of anyone who has), but that requires you to have Tcl
available. It's available for Linux, but not all distros include it
as a default.
I need to add awk to toybox because posix and because ./configure stages
of lots of packages use it.

But tcl is out of scope. (And only seems to be used for two things:
tcl/tk graphics whatsis that python finally mostly weaned itself off of,
and expect.)
Post by dmccunney
I recommend Brent Welch's "Practical Programming in Tcl and Tk" from
Prentice Hall as the best Tcl book I'm aware of. For Expect, you want
Don Libes' "Exploring Expect" published by O'Reilly.
Post by stephen Turner
https://lkubuntu.wordpress.com/2013/01/09/shbuild-an-alternative-to-gnu-make-using-shell-scripts/
I forget where I posted my make rant. Might have been a year or two back
on the toybox list? Ah no, it was on the aboriginal list (in two parts):

http://lists.landley.net/pipermail/aboriginal-landley.net/2011-June/000859.html
http://lists.landley.net/pipermail/aboriginal-landley.net/2011-June/000860.html

(And yes, I found that by googling for "landley make rant".)
Post by dmccunney
Post by stephen Turner
am i missing something or is gnu make the only Makefile processing make
program without adding additional dependencies like perl?
Another popular alternative is Scons (http://www.scons.org/), but
Scons requires Python.
Requiring python is pretty much a deal breaker. (As mercurial seems to
have discovered, having about 5% of the market share of git at this point.)

But the big problem is that rewriting the makefiles of existing projects
is a flaming pain. (As I'm sure enh could tell you, since Android is
apparently doing it. I'm not convinced their way of doing it is _better_
since it's still based on make, but I haven't looked too deeply yet.)
Post by dmccunney
Wikipedia has a list of build automation software -
http://en.wikipedia.org/wiki/List_of_build_automation_software
We need a rethink of build systems the way git/mercurial was a rethink
of cvs and svn. Unfortunately, there's a network effects thing where
crap like CVS being standardized outweighed the benefits of the new
thing unless you had a flagship like linux-kernel that can get you a
critical mass of new developers. We haven't got that for make. X11 tried
its own make for a while (imake?), Apache had Ant, and so on, but none
of it really made a dent.

Android could lead us to a new make system, but instead they layered
"repo" on top of git, rewrote existing makefiles but still did so using
"make", and gave us a bsd-style giant hairball build I'm still trying to
pick apart and extract individual packages and build flow from.

So "could", but "isn't yet". Maybe when their current build collapses
under its own weight and they do a 2.0 version, but given the amount of
engineering time they (and other companies) are throwing at it I expect
that's at least 5 years away, and there could still be an incremental
cleanup ala Joel Spolsky's advice from
http://www.joelonsoftware.com/articles/fog0000000069.html

(Also, we need to rethink all three stages, configure, make, and
install. But I've got my plate full just now...)

Rob
stephen Turner
2015-01-23 15:58:48 UTC
Permalink
Post by Rob Landley
I forget where I posted my make rant. Might have been a year or two back
http://lists.landley.net/pipermail/aboriginal-landley.net/2011-June/000859.html
http://lists.landley.net/pipermail/aboriginal-landley.net/2011-June/000860.html
(And yes, I found that by googling for "landley make rant".)
I found a number of rants about make, including one that discussed what he
was doing to get posix to improve the standard.

http://www.dwheeler.com/essays/make.html
Post by Rob Landley
Requiring python is pretty much a deal breaker. (As mercurial seems to
have discovered, having about 5% of the market share of git at this point.)
Adding dependencies is always a gamble for a project from what i have read.
Developers want less to fool with these days as it leverages many
advantages including less #$%^ to break.
Post by Rob Landley
But the big problem is that rewriting the makefiles of existing projects
is a flaming pain. (As I'm sure enh could tell you, since Android is
apparently doing it. I'm not convinced their way of doing it is _better_
since it's still based on make, but I haven't looked too deeply yet.)
Ahh, now i believe we are at the root of it. Make regardless of correctness
is ingrained in every project. Any new make that actually wants to gain a
foot hold would need to read existing and offer new. A replace only option
simply wont gain traction no matter how well written because the existing
infrastructure is "good enough"
Post by Rob Landley
We need a rethink of build systems the way git/mercurial was a rethink
of cvs and svn. Unfortunately, there's a network effects thing where
crap like CVS being standardized outweighed the benefits of the new
thing unless you had a flagship like linux-kernel that can get you a
critical mass of new developers. We haven't got that for make. X11 tried
its own make for a while (imake?), Apache had Ant, and so on, but none
of it really made a dent.
It would have been too much work for people to implement, As i see it
currently gnu-make has a proprietary hold on the make process because you
cannot easily install another make that can parse the same files. This is
where makepp had the better idea until they added a dependency of perl or
python.
Post by Rob Landley
Android could lead us to a new make system, but instead they layered
"repo" on top of git, rewrote existing makefiles but still did so using
"make", and gave us a bsd-style giant hairball build I'm still trying to
pick apart and extract individual packages and build flow from.
I dont understand why android digressed from a standard embedded linux in
the first place. But honestly im not concerned with them either. my phone
works and thats enough from android until the next big thing.
Post by Rob Landley
(Also, we need to rethink all three stages, configure, make, and
install. But I've got my plate full just now...)
Again you go back to bucking the norm, Its great, i do it all the time at
my day job but people are naturally lazy to change, only when its easy and
benefits them at the same time.

I'm debating getting involved in a make rewrite considering i would be
learning C as i develop it and that cant be a easy task. but to change the
process entirely at this point you would need something that also reads
from and accepts the old norm. Then allow the old to slowly die while you
wean the masses off of the proverbial tit.

One thing i need to test before i dig into this would be if the "posix
make" is good enough to compile lfs. If not then choices have to be made to
patch the program that faild or make depending on the mass effect. Atleast
having a starting point such as the Posix standard will set you up for the
least amount of work needed, from there a future of make what ever that may
be can be added on one feature at a time and hopefully pushed through posix
at the same time.

I think dwheeler had it right in that if you want make files to be
universally compatible you have to impose change on the standard that
everyone is looking to and the way i see it that may be the only way to
invoke change.

wow, i didn't mean to write a essay.

~Stephen
enh
2015-01-23 18:54:21 UTC
Permalink
Post by Rob Landley
Post by dmccunney
On Thu, Jan 22, 2015 at 10:54 AM, stephen Turner
Post by stephen Turner
so Gnu make isnt bad but it isnt that great either, I found what looks like
it might be a nice little make program but the depressing down side is it
uses a new language tcl. its so simple! I dont understand why stuff like
this doesnt catch on unless its not as good as they are making it out to be?
http://wiki.tcl.tk/9293
on a plus side it sounds like tcl is easy to learn. albiet its not as simple
as just writing a shell script for a makefile
Way back when I was looking at rewriting toybox in lua, but having to
cross compile a language runtime to a new architecture wasn't a huge
step up from having to cross compile a C binary.
I have a todo item to write a "make", either for toybox for for my
proposed qcc project (my old tcc fork + qemu's tcg Tiny Code Generator).
In either case, it's not until after 1.0.
I tried to build toybox under the bsd make in pcbsd, and... it did not
go well. Just getting kconfig (menuconfig) to build was enough of a
blocker I wandered off and did other things. My approach to gmake is
similar to my approach to bash: clone one that does enough of the same
stuff to migrate the existing users off, regardless of what subset may
be "standardized". If the standard isn't enough to support actual use
cases, then the standard is merely a frame of reference to diverge from
and from there you debug the use cases and add the things they need.
Post by dmccunney
Tcl is a scripting language created by John Ousterhout when he was a
Professor of Computer Science at UC. His students were developing a
network operating system called Amoeba. Dr. Ousterhout wrote Tcl to
be a glue language. Tk was added later as a means of providing
graphical widgets, and has been used in other efforts as well.
Tcl underlies Done Libes' Expect utility, which is just the thing if
you need to automate processes that are normally run interactively.
I've meant to write an "expect" in C for years as well, but I don't use
the existing expect enough to just knock off a version with the
semantics its existing users want.
To be honest when confronted with expect, I wrote my own version in
python because it was easier than learning anything about tcl. Since
then I've written shell and C versions, but I haven't tried to publish
them because I dunno how to use the existing tcl one. (I remember poking
at it for 15 minutes and being confused, and then writing a new one in
like 5. It's not that it's hard to learn, just that it really didn't
seem _worth_ it for what it was doing...)
(Yes, getting it to work in shell was fiddly: I had to use mkfifo.
There's almost certainly a better way but that's the one I got working
first. For years I've wanted a shell command called 'loop' that pipes
the output at the end of the command line back into the input at the
beginning. Maybe I'll put it in toysh.)
http://osdir.com/ml/linux.busybox/2004-01/msg00048.html . Sheesh, why
don't people steal my ideas and _implement_ them more often, so I don't
have to?)
The basic functionality is trivial to do in toybox because I already
wrote the hard bits in lib/xwrap.c function xpopen_both(). Example
usages (through two different wrappers) are in mount.c to call losetup
and swapon. But it parses some sort of config file and then maybe needs
regex searches to match things? And does it extract data from its input
and process it to produce output, or something?
Again: a possible todo item after 1.0. Not because it's hard to write
but because I don't know what the command should _do_. Expect has a
command script that apparently you can embed tcl snippets into, or
something? (I should go look at it, but it's waaaaaay down the todo list.)
Post by dmccunney
You could probably use Tcl to implement make functionality (though I'm
not aware of anyone who has), but that requires you to have Tcl
available. It's available for Linux, but not all distros include it
as a default.
I need to add awk to toybox because posix and because ./configure stages
of lots of packages use it.
...and you can't run the toybox tests without awk :-)

yes, there are reasons why you might not want toybox testing itself as
your only testing, but it's a nice little extra, and probably the
easiest way to actually run the tests on Android. any alternative
seems to involve adding "adb shell" all over the place. i have an open
bug for running the toybox tests, but haven't even started to look at
it yet. i've been running the tests on the host instead and doing
manual testing on devices.
Post by Rob Landley
tcl/tk graphics whatsis that python finally mostly weaned itself off of,
and expect.)
Post by dmccunney
I recommend Brent Welch's "Practical Programming in Tcl and Tk" from
Prentice Hall as the best Tcl book I'm aware of. For Expect, you want
Don Libes' "Exploring Expect" published by O'Reilly.
Post by stephen Turner
https://lkubuntu.wordpress.com/2013/01/09/shbuild-an-alternative-to-gnu-make-using-shell-scripts/
I forget where I posted my make rant. Might have been a year or two back
http://lists.landley.net/pipermail/aboriginal-landley.net/2011-June/000859.html
http://lists.landley.net/pipermail/aboriginal-landley.net/2011-June/000860.html
(And yes, I found that by googling for "landley make rant".)
Post by dmccunney
Post by stephen Turner
am i missing something or is gnu make the only Makefile processing make
program without adding additional dependencies like perl?
Another popular alternative is Scons (http://www.scons.org/), but
Scons requires Python.
Requiring python is pretty much a deal breaker. (As mercurial seems to
have discovered, having about 5% of the market share of git at this point.)
But the big problem is that rewriting the makefiles of existing projects
is a flaming pain. (As I'm sure enh could tell you, since Android is
apparently doing it. I'm not convinced their way of doing it is _better_
since it's still based on make, but I haven't looked too deeply yet.)
i idly complained about the strace "ioctl(1, SNDCTL_TMR_TIMEBASE or
SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon
echo ...}) = 0" behavior recently and the maintainer fixed it in a way
that involves more work at build time, so now i have to rewrite our
makefiles to cope :-(

trying to have one tree that supports six targets is a pain,
especially with no equivalent of a configure step.
Post by Rob Landley
Post by dmccunney
Wikipedia has a list of build automation software -
http://en.wikipedia.org/wiki/List_of_build_automation_software
We need a rethink of build systems the way git/mercurial was a rethink
of cvs and svn. Unfortunately, there's a network effects thing where
crap like CVS being standardized outweighed the benefits of the new
thing unless you had a flagship like linux-kernel that can get you a
critical mass of new developers. We haven't got that for make. X11 tried
its own make for a while (imake?), Apache had Ant, and so on, but none
of it really made a dent.
Android could lead us to a new make system, but instead they layered
"repo" on top of git, rewrote existing makefiles but still did so using
"make", and gave us a bsd-style giant hairball build I'm still trying to
pick apart and extract individual packages and build flow from.
So "could", but "isn't yet". Maybe when their current build collapses
under its own weight and they do a 2.0 version, but given the amount of
engineering time they (and other companies) are throwing at it I expect
that's at least 5 years away, and there could still be an incremental
cleanup ala Joel Spolsky's advice from
http://www.joelonsoftware.com/articles/fog0000000069.html
yeah, i wouldn't assume the final chapter has been written. i don't
know anyone who's satisfied with the current situation, but the build
system has never been the most urgent problem. (see also the current
crappy toybox-on-Android testing situation.)
Post by Rob Landley
(Also, we need to rethink all three stages, configure, make, and
install. But I've got my plate full just now...)
Rob
_______________________________________________
Toybox mailing list
http://lists.landley.net/listinfo.cgi/toybox-landley.net
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Java i18n/JNI/NIO, or bionic questions? Mail me/drop by/add me as a reviewer.
Isaac Dunham
2015-01-23 20:02:24 UTC
Permalink
Post by Rob Landley
tcl/tk graphics whatsis that python finally mostly weaned itself off of,
and expect.)
Post by dmccunney
I recommend Brent Welch's "Practical Programming in Tcl and Tk" from
Prentice Hall as the best Tcl book I'm aware of. For Expect, you want
Don Libes' "Exploring Expect" published by O'Reilly.
Post by stephen Turner
https://lkubuntu.wordpress.com/2013/01/09/shbuild-an-alternative-to-gnu-make-using-shell-scripts/
I forget where I posted my make rant. Might have been a year or two back
http://lists.landley.net/pipermail/aboriginal-landley.net/2011-June/000859.html
http://lists.landley.net/pipermail/aboriginal-landley.net/2011-June/000860.html
(And yes, I found that by googling for "landley make rant".)
Post by dmccunney
Post by stephen Turner
am i missing something or is gnu make the only Makefile processing make
program without adding additional dependencies like perl?
Another popular alternative is Scons (http://www.scons.org/), but
Scons requires Python.
Requiring python is pretty much a deal breaker. (As mercurial seems to
have discovered, having about 5% of the market share of git at this point.)
But the big problem is that rewriting the makefiles of existing projects
is a flaming pain. (As I'm sure enh could tell you, since Android is
apparently doing it. I'm not convinced their way of doing it is _better_
since it's still based on make, but I haven't looked too deeply yet.)
Post by dmccunney
Wikipedia has a list of build automation software -
http://en.wikipedia.org/wiki/List_of_build_automation_software
We need a rethink of build systems the way git/mercurial was a rethink
of cvs and svn. Unfortunately, there's a network effects thing where
crap like CVS being standardized outweighed the benefits of the new
thing unless you had a flagship like linux-kernel that can get you a
critical mass of new developers. We haven't got that for make. X11 tried
its own make for a while (imake?), Apache had Ant, and so on, but none
of it really made a dent.
imake was not X11's own make: it was an alternative to configure that
used the C preprocessor to generate makefiles.
The concept is that you can figure out how to do something for a given
OS, and then the build system #include's a config file that does that.
It's trivial to write an Imakefile, but debugging the result can be
somewhat difficult if you don't know that it's generated using cpp, or
the OS config files don't really match your system.

And yes, there are people still using it. The latest xterm is one
example, and another is cdesktopenv.
In case you don't know what that is:
cdesktopenv is the open source CDE project. I've contributed a couple
small bits to it. It takes me a few hours to build.
Recently, some GNU folks came in, wanted to replace the Imake build
system with Autoconf, got some objections, found out about the "we'd
/like/ to relicense to MIT down the road" bit, and pitched a fit and
said they'd fork it as a GNU project, talking about naming the fork
GDE.

ant is intended for Java; it's compatible with the build system used by
Eclipse.

The BSDs each have their own make; the freebsd-make and bmake/pmake
packages are ports of the freebsd and netbsd versions.

smake is probably close to gmake in how it interprets makefiles.
But I don't expect you'd want to touch it--it's Schilling's fork of
Solaris make.

There's an "amake" that's supposedly gmake compatible:
amake.sourceforge.net

cmake is a config system, but you've probably heard of it.
dmake is the OpenOffice build tool, which no-one else seems to use.
{e,f,h,j,k}make are Erlang, Fortran, Haskell, Java, and KDE "make" versions.
Some generate makefiles, some replace make.
lmake is either a Perl-based latex build tool or a Lua-based make
implementation.
qmake and tmake are Qt-related projects that generate makefiles.
nmake is (a) the Bell Labs make or (b) the MS "looks like make but
*needs* spaces instead of tabs" tool.

Basically, every letter except "u" is claimed; that's used for something
unrelated.

omake and xmake are extended make-like tools;
zmake and rmake are remote build tools.

HTH,
Isaac Dunham
Kartik Agaram
2015-01-23 19:13:45 UTC
Permalink
Post by Rob Landley
For years I've wanted a shell command called 'loop' that pipes
the output at the end of the command line back into the input at the
beginning. Maybe I'll put it in toysh.
http://osdir.com/ml/linux.busybox/2004-01/msg00048.html . Sheesh, why
don't people steal my ideas and _implement_ them more often, so I don't
have to?)
I came up with a klunky first draft that takes two arguments:

$ ./circle 'echo hi' ./append-something

The first argument primes the pump and the second is the one that will run
forever. I built it using a fifo:

= circle-1
mkfifo /tmp/foo
eval $1 >/tmp/foo &
eval $2 </tmp/foo |tee x > /tmp/foo

The 'tee' is to see that it's running. The '-v' option to also emit the
iterations to stdout I implemented with a second fifo:

= circle-2
mkfifo /tmp/foo
mkfifo /tmp/bar
eval $1 >/tmp/foo &
eval $2 </tmp/foo |tee /tmp/bar > /tmp/foo &
cat /tmp/bar

Finally, a test command I tried this with (this is where the loop goes,
right?):

= append-something
while read line
do
echo "$line a"
done

Comments appreciated. I'm not clear on the use for this, but it was an
interesting exercise. I'm sure there's cleaner ways to do this, especially
that second fifo.
Martin Kühl
2015-01-22 18:45:00 UTC
Permalink
On Thu, Jan 22, 2015 at 4:54 PM, stephen Turner
Post by stephen Turner
so Gnu make isnt bad but it isnt that great either, I found what looks like
it might be a nice little make program but the depressing down side is it
uses a new language tcl. its so simple! I dont understand why stuff like
this doesnt catch on unless its not as good as they are making it out to be?
http://wiki.tcl.tk/9293
on a plus side it sounds like tcl is easy to learn. albiet its not as simple
as just writing a shell script for a makefile
https://lkubuntu.wordpress.com/2013/01/09/shbuild-an-alternative-to-gnu-make-using-shell-scripts/
am i missing something or is gnu make the only Makefile processing make
program without adding additional dependencies like perl?
There's a make-like script on p. 178 of The AWK Programming Language[1]
and a (slightly cleaned up, it seems) descendant here[2].

[1] http://books.cat-v.org/computer-science/awk-programming-language/The_AWK_Programming_Language.pdf
[2] https://github.com/darius/ake
Rich Felker
2015-01-23 18:22:07 UTC
Permalink
Post by stephen Turner
so Gnu make isnt bad but it isnt that great either, I found what looks like
it might be a nice little make program but the depressing down side is it
uses a new language tcl. its so simple! I dont understand why stuff like
this doesnt catch on unless its not as good as they are making it out to
be?
http://wiki.tcl.tk/9293
on a plus side it sounds like tcl is easy to learn. albiet its not as
simple as just writing a shell script for a makefile
https://lkubuntu.wordpress.com/2013/01/09/shbuild-an-alternative-to-gnu-make-using-shell-scripts/
am i missing something or is gnu make the only Makefile processing make
program without adding additional dependencies like perl?
There are BSD make programs, but they're not compatible with makefiles
written for GNU make. I'm generally opposed to use of GNU extensions,
but in the case of make, they give it a lot more power to be used in
the way it _should_ be used: to describe the build process in a
declarative manner with simple, non-redundant rules based on patterns.
And as far as GNU programs go, GNU make is extremely clean, light, and
portable. It was working without modification on musl a long time
before that could be said about any other GNU software.

So to answer your question, I think the reason nothing else has caught
on is that GNU make is really "good enough" for most people except
those allergic to its license. I wouldn't be opposed to a compatible
permissive-licensed tool, but I also wouldn't want to spend time on
it, and I wouldn't want it to pull in dependencies on interpreters
like tcl, perl, python, etc...

Rich
stephen Turner
2015-01-23 20:00:03 UTC
Permalink
Post by Rich Felker
There are BSD make programs, but they're not compatible with makefiles
written for GNU make. I'm generally opposed to use of GNU extensions,
but in the case of make, they give it a lot more power to be used in
the way it _should_ be used: to describe the build process in a
declarative manner with simple, non-redundant rules based on patterns.
And as far as GNU programs go, GNU make is extremely clean, light, and
portable. It was working without modification on musl a long time
before that could be said about any other GNU software.
So to answer your question, I think the reason nothing else has caught
on is that GNU make is really "good enough" for most people except
those allergic to its license. I wouldn't be opposed to a compatible
permissive-licensed tool, but I also wouldn't want to spend time on
it, and I wouldn't want it to pull in dependencies on interpreters
like tcl, perl, python, etc...
Rich
Thanks Rich, i frown on and shy away from licenses these days like *gpl*
for the simple fact of not wanting to be liable for providing source etc if
i don't want to or being concerned if i met all the requirements for the
lawyers. I also feel *gpl* is largely avoided by companies for sheer
license purposes. ( points at mac, android )

However I don't think my personal issues with the gpl are bad enough yet to
warrant avoiding good programs just for the license. Seeing how everyone
feels about it and the fact that i cant find any reasonable and compatible
alternatives i feel it should be fine for my purposes.

As always thanks everyone for your input.

~Stephen
Daniel Cegiełka
2015-01-23 21:26:52 UTC
Permalink
Proposals such as awk, tcl or python does not make sense, if you still
need the GNU make, to compile the kernel, musl etc. + tcl/python as
deps...

Let us define the problem: we do not want GNU make ('allergic to its license').

Requirements: the ability to compile the _linux_ kernel, musl etc.

In my view, the most sensible solution is mk (MIT) port as a base +
compatibility layer with the GNU make.

http://doc.cat-v.org/bell_labs/mk/
http://git.2f30.org/mkbuild/tree/

Daniel
Kartik Agaram
2015-01-23 21:56:58 UTC
Permalink
Post by Rob Landley
For years I've wanted a shell command called 'loop' that pipes
the output at the end of the command line back into the input at the
beginning. Maybe I'll put it in toysh.
http://osdir.com/ml/linux.busybox/2004-01/msg00048.html . Sheesh, why
don't people steal my ideas and _implement_ them more often, so I don't
have to?)
I came up with a klunky first draft that takes two arguments:

$ ./circle 'echo hi' ./append-something

The first argument primes the pump and the second is the one that will run
forever. I built it using a fifo:

= circle-1
mkfifo /tmp/foo
eval $1 >/tmp/foo &
eval $2 </tmp/foo |tee x > /tmp/foo

The 'tee' is to see that it's running. The '-v' option to also emit the
iterations to stdout I implemented with a second fifo:

= circle-2
mkfifo /tmp/foo
mkfifo /tmp/bar
eval $1 >/tmp/foo &
eval $2 </tmp/foo |tee /tmp/bar > /tmp/foo &
cat /tmp/bar

Finally, a test command I tried this with (this is where the loop goes,
right?):

= append-something
while read line
do
echo "$line a"
done

Comments appreciated. I'm not clear on the use for this, but it was an
interesting exercise. I'm sure there's cleaner ways to do this, especially
that second fifo.

Continue reading on narkive:
Loading...