Version 16 (modified by coke, 12 years ago)



  • most file generation should be done via make, not Config. To see what files are generated by your configure, make realclean; perl; svn st --no-ignore.
    • ext/Parrot-Embed/Makefile.PL should not be generated; it should just use Parrot::Config to get @ this config-time information.
    • the steps that generate PMC related info don't have to happen at config time. move them into the build.
  • accurate build dependencies
  • should verify perl dependencies.
  • should verify pir deps.
  • should be able to generate makefiles, not just verify them.
  • recursive make is bad. Avoid it where possible, esp for anything built with the default target.
    • eliminate the recursive 'docs' target.
    • eliminate the recursive 'dynoplibs' target.
    • eliminate the recursive 'dynpmc' target.
  • avoid make targets with two+ targets on the left; parallel make is allowed to call this rule twice, which is probably not what you want.
    • make squawk about this, to make them easier to find and replace?
  • Instead of invoking $(CC) directly, we invoke tools/dev/ to invoke CC for us. We should use the c compiler directly instead; to support the cases where is using customized flags for a particular build step, that should be handled in the generated makefile, not by running a script to figure it out at build time. ./CFLAGS is currently generated from a file that is using the conditional makefile syntax. Once we start generating the dependencies manually, we can generate manual rules for anything that requires non-standard CFLAGS.

Originally from

This script will currently generate false positives.  This happens because it
assumes that there must be a fixed relationship between source and object
files, e.g. C<buz/baz/foo.pir> will be built into C<buz/baz/foo.pbc>.

assumption holds in most cases but breaks down when a file with a dependency is
not compiled into an object file of the same name.  A possible solution to this
is to use C-style compilation with separate build and "link" targets using
pbc_merge.  The other alternative involves making this script significantly
smarter about figuring out which rules create a given object file.

- the plan here should be to have all pir that gets compiled initially be compiled to a pbc in the same directory (just like the standard .c->.o compilation process) - if we then need a separate rule to copy the built pbc to an "install" directory, that's fine; having the two stages should let us track the deps more automatically.

Some tickets: #576 #382 #1214 #338 #1285 #1418


  • should interpolate variables like make does when checking make. (not all at once at the end, but as-we-go.)
  • Specifically: eliminate parrot_include step.

one_make branch was merged into trunk Jan 25 2010 09:44 PM ET in r43593

At merge point, this was what tools/dev/ was showing:

$ perl tools/dev/ 2>&1 | grep 'not ok'     
not ok 62 - src/glut_callbacks.c has correct dependencies (Makefile: line 3509).
not ok 119 - compilers/data_json/data_json.pir has correct dependencies 
  (compilers/data_json/Rules.mak: line 1).
not ok 120 - compilers/json/JSON.pir has correct dependencies 
  (compilers/json/Rules.mak: line 1).
not ok 122 - compilers/json/JSON/pge2pir.pir has correct dependencies 
  (no rule found for this file).
not ok 127 - compilers/nqp/bootstrap/nqp.pir has correct dependencies 
  (compilers/nqp/Rules.mak: line 21).
not ok 137 - compilers/pct/src/PCT/Grammar.pir has correct dependencies 
  (no rule found for this file).
not ok 142 - compilers/pge/PGE.pir has correct dependencies 
  (no rule found for this file).
not ok 146 - compilers/pge/PGE/P5Regex.pir has correct dependencies 
  (no rule found for this file).