Giter VIP home page Giter VIP logo

Comments (4)

samuelgruetter avatar samuelgruetter commented on July 24, 2024

I'm trying to understand why these 4 dependencies of the test target are always run:

test: special/BytedumpTest.out typecheckExprToCString testStackLoop testStackNondet # typecheckExprToCString-32 typecheckExprToCString-64

For typecheckExprToCString, testStackLoop, testStackNondet, I think one reason is that they don't create a file with that name, so running these tests does not leave any trace of when it has been run last, so make has to rerun it each time. An easy fix for these would probably be to have the tests create a .ok file.
So I tried the following patch in bedrock2/Makefile:

        $(BYTEDUMP) bedrock2.ToCStringStackallocLoopTest.main_cbytes > special/stackloop.c
 special/stackloop: special/stackloop.c
        $(CC) -O0 special/stackloop.c -o special/stackloop
-testStackLoop: special/stackloop
-       special/stackloop
+special/stackloop.ok: special/stackloop
+       special/stackloop > $@
+testStackLoop: special/stackloop.ok
 
 special/stacknondet.c: ex
        $(BYTEDUMP) bedrock2Examples.stackalloc.stacknondet_c > special/stacknondet.c

But it seems that stackloop is still rerun each time.

And I also don't understand why this code, creating special/BytedumpTest.out, is rerun each time:

special/BytedumpTest.out: special/BytedumpTest.golden.bin noex
$(BYTEDUMP) bedrock2.PrintListByte.allBytes > special/BytedumpTest.out.tmp
hexdump < /dev/null && \
hexdump -C special/BytedumpTest.golden.bin > special/BytedumpTest.golden.hex && \
hexdump -C special/BytedumpTest.out.tmp > special/BytedumpTest.out.hex && \
diff -u special/BytedumpTest.golden.hex special/BytedumpTest.out.hex && \
rm special/BytedumpTest.golden.hex special/BytedumpTest.out.hex || true
diff -u special/BytedumpTest.golden.bin special/BytedumpTest.out.tmp
mv special/BytedumpTest.out.tmp special/BytedumpTest.out

Do you understand this @JasonGross ?

from bedrock2.

JasonGross avatar JasonGross commented on July 24, 2024

ex and noex are declared PHONY, so they are considered out of date on every run. Since they are remade, all targets that list them as prerequisites are also considered out of date (much like how force is used). The solution is to make them order-only dependencies, as in special/BytedumpTest.out: special/BytedumpTest.golden.bin | noex and special/stacknondet.c: | ex, etc. An order only dependency is a prerequisite that does not cause a recipe to be re-run if it is out of date.

(I guess you want something like

special/stacknondet.c: bedrock2Examples.stackalloc.stacknondet_c $(BYTEDUMP) | ex
$(BYTEDUMP): | ex

to ensure that special/stacknondet.c is remade when BYTEDUMP changes? Or you make it depend (not order-only) on whatever files it actually uses

from bedrock2.

samuelgruetter avatar samuelgruetter commented on July 24, 2024

Aah thanks for explaining me order-only prerequisites 👍

But I'm still a bit confused, and can't resolve it using google. Let's say I have

mytarget: fileProducedBy_ex | ex
        myrecipe

and running ex might modify fileProducedBy_ex. Now, when does make determine whether mytarget is out of date? I guess before running ex? That would be unfortunate, because if ex updates fileProducedBy_ex, I would like mytarget to be rebuilt -- is there a way to achieve that?

from bedrock2.

JasonGross avatar JasonGross commented on July 24, 2024

You can make ex an order-only dependency of fileProducedBy_ex without a recipe.


Details:

I'm not sure, but I think:

  • if fileProducedBy_ex does not exist and there's no explicit mention of it, make will error before trying ex
  • if fileProducedBy_ex either already exists or has a(n order-only) dependency on some other target, make mytarget will first invoke all dependencies and order-only dependencies of mytarget and only after completing these dependencies will it determine whether or not the rule for mytarget should be run.

That is, my mental model is:

  1. First make walks the entire dependency chain of targets that need to be refreshed to build the dependency tree. In this step there is no difference between normal dependency and order-only dependency
  2. Then make does a (possibly parallel) traversal of the dag from the leaves to the roots. Once make has traversed all the children of a node, it will rebuild the current node only if there are any non-order-only dependencies which are newer than the current target. (PHONY targets are always considered newer; not sure how non-file non-PHONY targets are handled)

from bedrock2.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.