Parse error after reordering rules in Tupfile

[kkosciusz]

Working Tupfile

: file1 |> cat file1 > file2 |> file2
: file2 |> cat file2 > file3 |> file3

Broken Tupfile

: file2 |> cat file2 > file3 |> file3
: file1 |> cat file1 > file2 |> file2

The output after running after fresh tup init is:

tup error: Explicitly named file 'file2' not found in subdir '.'
tup error: Error parsing Tupfile line 1
  Line was: ': file2 |> cat file2 > file3 |> file3'

My system is 64-bit Windows 7, tup --version returns tup v0.7.3-42-g13068bc

[gittup]

On Fri, Nov 6, 2015 at 9:13 AM, kkosciusz notifications@github.com wrote:

Working Tupfile

: file1 |> cat file1 > file2 |> file2
: file2 |> cat file2 > file3 |> file3

Broken Tupfile

: file2 |> cat file2 > file3 |> file3
: file1 |> cat file1 > file2 |> file2

This is the expected behavior - outputs have to be defined before they can
be used by another rule. This may change in the future, though for now this
is not a bug. Is there a particular use-case that you have where the rules
cannot be ordered in this way?

[kkosciusz]

I was under impression that the rules are fully declarative so the order does not matter, possibly due to my experience with make.

After reading the manual more carefully I can see the sentence:

Once a file is specified in an output section, it is put into the tup database. Any following rules can use that file as an input, even if it doesn't exist in the filesystem yet.

There is no special case where I cannot order the rules; I guess I have been caught by surprise by this behavior of tup.

[gittup]

On Fri, Nov 6, 2015 at 4:09 PM, kkosciusz notifications@github.com wrote:

I was under impression that the rules are fully declarative so the order
does not matter, possibly due to my experience with make.

After reading the manual more carefully I can see the sentence:

Once a file is specified in an output section, it is put into the tup
database. Any following rules can use that file as an input, even if it
doesn't exist in the filesystem yet.

There is no special case where I cannot order the rules; I guess I have
been caught by surprise by this behavior of tup.

Yeah, I can see how that can be confusing coming from make. Like I said, we
may change tup to do that in the future, but at the moment there hasn't
been a driving factor. One reason I am considering it is that it would
allow tup to parse each Tupfile in a silo - right now, if you specify
"foo/bar.o" as an input, tup will halt parsing the current Tupfile and
start parsing foo/Tupfile. If one of the Tupfiles has an error, tup will
have to re-parse both. Whereas if we could parse each individually, then
only the Tupfile that has an error would need to be re-parsed. It's a
fairly minor benefit, but I think it would be nice to have.

-Mike