On Mon, Feb 7, 2011 at 6:20 PM, Alan Silverstein <[email protected]> wrote:
>
>> Also some systems require recursion. The best example is LaTeX. This
>> requires a concept of fixpoints, that is, you run latex repeatedly
>> until the output doesn't change (this is because things like plugging
>> in cross references change layout, which change the cross-references).
>
> Yuck. Cyclical build graphs are anathema and should be completely
> avoided because no one ever builds them correctly. I dispute your
> assertion that "some systems require recursion." Good design should
> avoid it. When "magic happens here" is a design rule, miraculous bugs
> follow.
I wish we could avoid it, but we don't have that luxury if we want
anyone to use fbuild with LaTeX. However, even though cyclical build
graphs are obnoxious, but it's pretty easy to handle if you're using
the build-system-as-a-cache model that fbuild uses, since you can fall
back onto loops or recursion pretty simply.
>> Fbuild is a caching build system. It caches the results of various
>> operations (compiling stuff, etc) and knows when the caches are not up
>> to date. So rebuilding is the same as building, except the caching
>> allow skipping some parts of the build because the dependencies tell
>> fbuild the results will be the same.
>
> Cool, that's the right concept.
Glad you think so!
>
>> Fbuild captures dependencies automatically, you not only don't have to
>> specify them .. you CANNOT specify them.
>
> Caution, you appear to be headed down the same path as (now what was the
> name again of Rational Software's kernel-incestuous over-the-top version
> control and build package?) You couldn't swat a fly in that system
> without first getting a doctoral thesis!
I think what skaller means here is that dependencies are expressed
through the evaluation of the python stack. fbuild at it's core is
just a way to attribute functions with the inputs and outputs. To
flesh out skaller's example into a full example:
---------------
import fbuild.db
@fbuild.db.caches
def cc(ctx, src:fbuild.db.SRC, dst) -> fbuild.db.DST:
dst = ctx.buildroot / dst
ctx.execute('touch %s' % dst)
return dst
def build(ctx):
cc(ctx, "mycode.c", "myout.o")
---------------
This is just creating a simple cached function that in addition to
memoizing the return value, also gives fbuild enough information to
know that the second argument is a file, and that the return value is
also a file. fbuild then can use this to decide whether or not to
rerun the function the next time it's called. It can also properly
handle a python list of files if you use the "fbuild.db.DSTS"
attribute for multiple target generation.
Layered on top of this is a bunch of functionality. For instance, this
is the driver script for compiling a simple C example:
https://github.com/erickt/fbuild/blob/master/examples/c/fbuildroot.py
You find my judy build system here:
https://github.com/erickt/felix/blob/master/buildsystem/judy.py
>> So you see with fbuild, you basically just tell it how to build the
>> system, the optimisation is automatic.
>
> Exceptions prove the rule, and wreck the budget. -- Miller
>
> How do you let people specify unusual dependencies that aren't as simple
> as compile this-to-that?
Do you have an example? So far everything I've seen can be modeled as
a function with X arguments, Y explicit results (which are directly
returned and used) and Z implicit results (which are a side effect of
the function, but no one needs to directly handle those results). For
instance, compiling an O'Caml file .ml file can generate both a .cmo
and a .cmi file, but the O'Caml linker only cares about the .cmo file.
In this case, the pseudo code is something like:
@fbuild.db.caches
def compile_ocaml(ctx, src:fbuild.db.SRC) -> fbuild.db.DST:
dst_cmi = src.replaceext('.cmi')
dst_cmo = src.replaceext('.cmo')
...
# let the database know that we also depend on the .cmi file.
ctx.db.add_external_reference(srcs=[dst_cmi])
return dst_cmo
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel
