Package maintainers and Hackage trustees are allowed to edit certain bits
of package metadata after a release, without uploading a new tarball.
Note that the tarball itself is never changed, just the metadata that is
stored separately. For more information about metadata revisions, please
refer to the
Hackage Metadata Revisions FAQ.
No. |
Time |
User |
SHA256 |
-r3 (Grow-1.1.0.3-r3) |
2014-07-13T15:03:59Z |
MarcCoiffier |
e599aab8eefc612bbf1dbae0b60308305a9d3009dda186b228e4e8aeeda1f36a
|
|
|
-r2 (Grow-1.1.0.3-r2) |
2014-07-13T12:01:09Z |
MarcCoiffier |
7b757afd0af5ce54b56bb196157fbf114e0d98c3ab1e2654cbb3e9bc538896d1
|
|
Changed description
from Grow is a well-defined replacement for Makefiles and the like to build complex
hierarchies of files with minimal effort.
Like many Makefile-like tools, Grow depends on the notion of
timestamps to determine whether a file should be recompiled or
not. Grow is much simpler than those, though, and I might argue way
easier to use as well.
On startup, Grow will look for a file named "Seed" in the current
directory, and evaluate the grow expressions contained within.
For example, here is a simple Seed file to compile a single C file
into an executable.
@
tee $$arg:in {
  all = ($main:seq "All done !"):in $execs
  execs = hook ld [main] [main.o] :in $objects
  objects = hook cc [main.o] [main.c]
}
@
Notice the `hook` function ? It is the Grow primitive that calls an
external program to perform actual tasks.
In Grow, hooks are expected to only accept files as their arguments,
so we have to write the wrapper scripts `cc` and `ld` that accept
arguments in the form "<destination>... <source>...". They are pretty
trivial to write since they only involve renaming variables and
swapping arguments.
Here are sample `cc` and `ld` scripts to show you there is nothing
magical about them :
> #!/bin/bash
> obj="$1" ; shift ; src="$1"
> gcc -c "$src" -o "$obj"
> #!/bin/bash
> bin="$1" ; shift ; obj="$1"
> gcc "$obj" -o "$bin"
In grow, instead of writing recipes in the configuration, we just declare
hooks and then write the appropriate wrapper scripts to call compilers with
the correct flags and arguments.
to Grow is a well-defined replacement for Makefiles and the like to build complex
hierarchies of files with minimal effort.
Like many Makefile-like tools, Grow depends on the notion of
timestamps to determine whether a file should be recompiled or
not. Grow is much simpler than those, though, and I might argue way
easier to use as well.
On startup, Grow will look for a file named "Seed" in the current
directory, and evaluate the grow expressions contained within.
For example, here is a simple Seed file to compile a single C file
into an executable.
> tee $$arg:in {
> all = ($main:seq "All done !"):in $execs
> execs = hook ld [main] [main.o] :in $objects
> objects = hook cc [main.o] [main.c]
}
Notice the `hook` function ? It is the Grow primitive that calls an
external program to perform actual tasks.
In Grow, hooks are expected to only accept files as their arguments,
so we have to write the wrapper scripts `cc` and `ld` that accept
arguments in the form "<destination>... <source>...". They are pretty
trivial to write since they only involve renaming variables and
swapping arguments.
Here are sample `cc` and `ld` scripts to show you there is nothing
magical about them :
> #!/bin/bash
> obj="$1" ; shift ; src="$1"
> gcc -c "$src" -o "$obj"
> #!/bin/bash
> bin="$1" ; shift ; obj="$1"
> gcc "$obj" -o "$bin"
In grow, instead of writing recipes in the configuration, we just declare
hooks and then write the appropriate wrapper scripts to call compilers with
the correct flags and arguments.
|
-r1 (Grow-1.1.0.3-r1) |
2014-07-13T11:42:39Z |
MarcCoiffier |
041592069bedb5c34fc50c32306d5c87db999ecda0e00dd32ea78b2ea8dec28c
|
|
Changed description
from Grow is a well-defined replacement for Makefiles and the like to build complex
hierarchies of files with minimal effort.
Like many Makefile-like tools, Grow depends on the notion of
timestamps to determine whether a file should be recompiled or
not. Grow is much simpler than those, though, and I might argue way
easier to use as well.
On startup, Grow will look for a file named "Seed" in the current
directory, and evaluate the grow expressions contained within.
For example, here is a simple Seed file to compile a single C file
into an executable.
> tee $$arg:in {
> all = ($main:seq "All done !"):in $execs
> execs = hook ld [main] [main.o] :in $objects
> objects = hook cc [main.o] [main.c]
> }
Notice the `hook` function ? It is the Grow primitive that calls an
external program to perform actual tasks.
In Grow, hooks are expected to only accept files as their arguments,
so we have to write the wrapper scripts `cc` and `ld` that accept
arguments in the form "<destination>... <source>...". They are pretty
trivial to write since they only involve renaming variables and
swapping arguments.
Here are sample `cc` and `ld` scripts to show you there is nothing
magical about them :
> #!/bin/bash
> obj="$1" ; shift ; src="$1"
> gcc -c "$src" -o "$obj"
> #!/bin/bash
> bin="$1" ; shift ; obj="$1"
> gcc "$obj" -o "$bin"
In grow, instead of writing recipes in the configuration, we just declare
hooks and then write the appropriate wrapper scripts to call compilers with
the correct flags and arguments.
to Grow is a well-defined replacement for Makefiles and the like to build complex
hierarchies of files with minimal effort.
Like many Makefile-like tools, Grow depends on the notion of
timestamps to determine whether a file should be recompiled or
not. Grow is much simpler than those, though, and I might argue way
easier to use as well.
On startup, Grow will look for a file named "Seed" in the current
directory, and evaluate the grow expressions contained within.
For example, here is a simple Seed file to compile a single C file
into an executable.
@
tee $$arg:in {
  all = ($main:seq "All done !"):in $execs
  execs = hook ld [main] [main.o] :in $objects
  objects = hook cc [main.o] [main.c]
}
@
Notice the `hook` function ? It is the Grow primitive that calls an
external program to perform actual tasks.
In Grow, hooks are expected to only accept files as their arguments,
so we have to write the wrapper scripts `cc` and `ld` that accept
arguments in the form "<destination>... <source>...". They are pretty
trivial to write since they only involve renaming variables and
swapping arguments.
Here are sample `cc` and `ld` scripts to show you there is nothing
magical about them :
> #!/bin/bash
> obj="$1" ; shift ; src="$1"
> gcc -c "$src" -o "$obj"
> #!/bin/bash
> bin="$1" ; shift ; obj="$1"
> gcc "$obj" -o "$bin"
In grow, instead of writing recipes in the configuration, we just declare
hooks and then write the appropriate wrapper scripts to call compilers with
the correct flags and arguments.
|
-r0 (Grow-1.1.0.3-r0) |
2014-07-13T11:32:13Z |
MarcCoiffier |
0a7db6bd08ff404dfe9dd147193f1dcc685dc5c304dc9d32823dc492a58c22e3
|
|
|