"run script" rules do no work, output of same script copy-pasted into Tupfile - does #36

Closed
adept opened this Issue Oct 22, 2011 · 4 comments

Comments

Projects
None yet
2 participants

adept commented Oct 22, 2011

Hi!

I ran in the following issues:

I am trying to generate rules using "run scipt" syntax. However it looks like some (or all?) order-only inputs in the script output are ignored. This leads to:
1)Commands being executed in the wrong order
2)Tup complaining that commands are reading from files not listed as dependencies (when in fact they are listed in the order-only inputs

However, when I take output of the script, copy-paste it into Tupfile and run "tup upd", everything works as expected.

Output of the script could be seen in
https://github.com/adept/tup-ocaml/blob/2cd3c04e3296418d45a0c20737eb0edfa401bffd/sexplib/lib/Tupfile
, starting from line 61 and till the end of file

For reference, the error I am getting when running "tup upd" after cleaning out all build artefacts looks like this:

[    0/17   ] sexplib/lib: ocamlc -I +camlp4 -I ../../lib  -pp 'cpp -traditional -undef' -c conv_error.ml -o conv_error.cmo
 *** tup: stderr ***
File "conv_error.ml", line 29, characters 0-9:
Error: Unbound module Conv
 *** Command 824 failed with return value 2: ocamlc -I +camlp4 -I ../../lib  -pp 'cpp -traditional -undef' -c conv_error.ml -o conv_error.cmo
tup error: Missing input dependency - a file was read from, and was not specified as an input link for the command. This is an issue because the file was created from another command, and without the input link the commands may execute out of order. You should add this file as an input, since it is possible this could randomly break in the future.
 -- Command ID: 824
 - [773] sexplib/lib/conv.cmi
 *** Additionally, command 824 failed to process input dependencies. These should probably be fixed before addressing the command failure.
Owner

gittup commented Oct 23, 2011

On Sat, Oct 22, 2011 at 6:54 PM, Dmitry Astapov
reply@reply.github.com
wrote:

Hi!

I ran in the following issues:

I am trying to generate rules using "run scipt" syntax. However it looks like some (or all?) order-only inputs in the script output are ignored. This leads to:
1)Commands being executed in the wrong order
2)Tup complaining that commands are reading from files not listed as dependencies (when in fact they are listed in the order-only inputs

However, when I take output of the script, copy-paste it into Tupfile and run "tup upd", everything works as expected.

Output of the script could be seen in
https://github.com/adept/tup-ocaml/blob/2cd3c04e3296418d45a0c20737eb0edfa401bffd/sexplib/lib/Tupfile
, starting from line 61 and till the end of file

Hi Dmitry,

Can you send the run script itself that you are using? It is possible
that the script is running differently within tup than when you run it
manually at the command-line. In particular, tup overrides the
readdir() function of the file-system, so that could cause the
behavior to be different. I should probably add a debugging function
for that, maybe I can do it tomorrow.

Thanks,
-Mike

adept commented Oct 23, 2011

On Sun, Oct 23, 2011 at 2:34 AM, gittup <
reply@reply.github.com>wrote:

On Sat, Oct 22, 2011 at 6:54 PM, Dmitry Astapov
reply@reply.github.com
wrote:

Hi!

I ran in the following issues:

I am trying to generate rules using "run scipt" syntax. However it looks
like some (or all?) order-only inputs in the script output are ignored. This
leads to:
1)Commands being executed in the wrong order
2)Tup complaining that commands are reading from files not listed as
dependencies (when in fact they are listed in the order-only inputs

However, when I take output of the script, copy-paste it into Tupfile and
run "tup upd", everything works as expected.

Output of the script could be seen in

https://github.com/adept/tup-ocaml/blob/2cd3c04e3296418d45a0c20737eb0edfa401bffd/sexplib/lib/Tupfile
, starting from line 61 and till the end of file

Hi Dmitry,

Can you send the run script itself that you are using? It is possible
that the script is running differently within tup than when you run it
manually at the command-line. In particular, tup overrides the
readdir() function of the file-system, so that could cause the
behavior to be different. I should probably add a debugging function
for that, maybe I can do it tomorrow.

Hi!

Thank you for the prompt response!

The script is the part of the same github repo. Here it is:

https://github.com/adept/tup-ocaml/blob/master/sexplib/lib/orules

It relies on ocamldep (from ocaml base package) and ocamldsort, which should
be in any reasonably bin Linux distro in the separate package.

Thanks,
-Mike

Reply to this email directly or view it on GitHub:
#36 (comment)

Dmitry Astapov

Owner

gittup commented Oct 24, 2011

On Sun, Oct 23, 2011 at 6:12 AM, Dmitry Astapov
reply@reply.github.com
wrote:

On Sun, Oct 23, 2011 at 2:34 AM, gittup <
reply@reply.github.com>wrote:

On Sat, Oct 22, 2011 at 6:54 PM, Dmitry Astapov
reply@reply.github.com
wrote:

Hi!

I ran in the following issues:

I am trying to generate rules using "run scipt" syntax. However it looks
like some (or all?) order-only inputs in the script output are ignored. This
leads to:
1)Commands being executed in the wrong order
2)Tup complaining that commands are reading from files not listed as
dependencies (when in fact they are listed in the order-only inputs

However, when I take output of the script, copy-paste it into Tupfile and
run "tup upd", everything works as expected.

Output of the script could be seen in

https://github.com/adept/tup-ocaml/blob/2cd3c04e3296418d45a0c20737eb0edfa401bffd/sexplib/lib/Tupfile
, starting from line 61 and till the end of file

Hi Dmitry,

Can you send the run script itself that you are using? It is possible
that the script is running differently within tup than when you run it
manually at the command-line. In particular, tup overrides the
readdir() function of the file-system, so that could cause the
behavior to be different. I should probably add a debugging function
for that, maybe I can do it tomorrow.

Hi!

Thank you for the prompt response!

The script is the part of the same github repo. Here it is:

https://github.com/adept/tup-ocaml/blob/master/sexplib/lib/orules

It relies on ocamldep (from ocaml base package) and ocamldsort, which should
be in any reasonably bin Linux distro in the separate package.

Well I was able to download and build your project, but then I hit an
annoying bug in tup (t6060) so unfortunately I had to fix that and
didn't get to look much into the issue. I hope to take another look
tomorrow. Some advice so far though:

  • I don't think it is a good idea to check-in the .tup directory.
    Someone else should be able to clone your repo, then 'tup init' and
    'tup upd'. (Or if they clone it as a subdirectory of a larger project
    that already was tup init'd, then they just 'tup upd'). There are
    things in the database like the last modification times that won't
    match on any system but yours.
  • You can use the '.gitignore' directive in a Tupfile to
    automatically generate the .gitignore files. These will match exactly
    the set of files that tup generates, rather than relying on you to
    specify an accurate set of ignores. I usually put it in the top-level
    Tuprules.tup file, so that way Tupfiles will pick it up if they are
    doing 'include_rules'. If there is a top-level Tupfile, this will also
    be set to ignore the .tup directory itself so you don't accidentally
    check it in.

That's it so far - you'll want to pull the latest master to make sure
you don't hit the same issue. Sorry I haven't actually answered your
question yet - the bug took a while to dig into.

-Mike

Owner

gittup commented Feb 14, 2012

I believe the issue of running differently in a run-script was something in ocamldep doing an ioctl on stdin, which fails since stdin is redirected to /dev/null. It is strange because ocamldep is not actually reading anything from stdin.

@gittup gittup closed this Feb 14, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment