generated command #88

Open
jjacobsson opened this Issue Nov 29, 2012 · 6 comments

Projects

None yet

2 participants

@jjacobsson

I tried to use a resulting executable from linking in a command and tup fails with

tup error: Unable to create command 'fptest.exe' because the node already exists in the database as type 'generated file'
tup error: Error parsing Tupfile line 29

My rules are:

: foreach *.cpp |> !cc |> 
: *.obj |> !exe |> fptest.exe
: |> fptest.exe |> image.jpg

Implement cc & exe rules as appropriate for your tool chain.

Owner
gittup commented Nov 29, 2012

On Thu, Nov 29, 2012 at 8:40 AM, Joacim Jacobsson
notifications@github.comwrote:

I tried to use a resulting executable from linking in a command and tup
fails with

tup error: Unable to create command 'fptest.exe' because the node already exists in the database as type 'generated file'
tup error: Error parsing Tupfile line 29

My rules are:

: foreach *.cpp |> !cc |>
: *.obj |> !exe |> fptest.exe
: |> fptest.exe |> image.jpg

Implement cc & exe rules as appropriate for your tool chain.

As a workaround, can you do:

: |> ./fptest.exe |> image.jpg

This seems to work for me. The reason you get this error is because both
filenames and command strings go into the same part of the database (bad
design decision on my part), so the "fptest.exe" in the file-system
conflicts with the "fptest.exe" command string in the third rule. If that
doesn't work for some reason let me know and I can try to find a way to
separate the namespaces.

-Mike

Sorry for not getting back until now.

Yes the workaround works. Thanks!

Maybe not the most elegant solution for a civilized age but it does work. :)

@jjacobsson jjacobsson closed this Dec 4, 2012

After some further testing...

This will indeed cause the built command to be executed. But, since the command is different than the produced file, tup fails to realize the dependency properly and thus runs the command before linking when you build a second time.

Maybe a different issue, but I will re-open this for visibility for now...

Rules now look like this:

: foreach *.cpp |> !cc |> {objs}
: {objs} |> !link_exe |> fptest.exe
: fptest.exe |> ./fptest.exe |> image.jpg
@jjacobsson jjacobsson reopened this Dec 4, 2012
Owner
gittup commented Dec 14, 2012

On Tue, Dec 4, 2012 at 7:43 AM, Joacim Jacobsson
notifications@github.comwrote:

After some further testing...

This will indeed cause the built command to be executed. But, since the
command is different than the produced file, tup fails to realize the
dependency properly and thus runs the command before linking when you build
a second time.

Maybe a different issue, but I will re-open this for visibility for now...


Reply to this email directly or view it on GitHubhttps://github.com/gittup/tup/issues/88#issuecomment-10995091.

If you leave out the dependency on fptest.exe, you should be getting an
error message like this:

$ cat Tupfile
!cc = |> gcc -c %f -o %o |> %B.obj
!exe = |> gcc %f -o %o |>

: foreach *.c |> !cc |>
: *.obj |> !exe |> fptest.exe
: |> ./fptest.exe |>

$ tup upd
[ tup ] [0.000s] Scanning filesystem...
[ tup ] [0.000s] Reading in new environment variables...
[ tup ] [0.000s] No Tupfiles to parse.
[ tup ] [0.000s] No files to delete.
[ tup ] [0.000s] Executing Commands...

  • 100% 1) ./fptest.exe
    Hey
    *** tup errors ***
    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.
    • [27] fptest.exe
      *** Command ID=20 ran successfully, but tup failed to save the
      dependencies.
      *** tup: 1 job failed.

Which is telling you that you need to specify fptest.exe as an input:

: fptest.exe |> ./fptest.exe |>

If you aren't getting that first error message, that sounds like a bug. Can
you provide a more complete test case? I'm not sure what your !cc and !exe
rules look like. Also, are you running in a Cygwin shell, or cmd shell, or
what else? What version of Windows?

Thanks,
-Mike

DEFINES += /D_DEBUG
DEFINES += /DDEBUG
DEFINES += /D_CONSOLE
DEFINES += /D_CRT_SECURE_NO_WARNINGS
DEFINES += /D_UNICODE
DEFINES += /DUNICODE

CCFLAGS += /nologo
CCFLAGS += /c
CCFLAGS += /errorReport:prompt
CCFLAGS += /wd4530
CCFLAGS += /wd4305
CCFLAGS += /wd4244
CCFLAGS += /W3
CCFLAGS += /TP
CCFLAGS += /Od
CCFLAGS += /Z7

LINKFLAGS += /nologo
LINKFLAGS += /DEBUG
LINKFLAGS += /INCREMENTAL:NO
LINKFLAGS += /SUBSYSTEM:CONSOLE

!link_exe = |> ^ Linking %o^ link $(LINKFLAGS) %f /OUT:%o /PDB:%O.pdb |> %O.pdb %O.ilk
!cc = |> ^ Compiling %f^ cl %f $(CCFLAGS) $(DEFINES) /Fo%B.obj |> %B.obj 

: foreach *.cpp |> !cc |> {objs}
: {objs} |> !link_exe |> fptest.exe
: fptest.exe |> ./fptest.exe |> image.jpg

That is my full Tupfile. And as you see I'm using Visual Studio (actually just the Windows SDK) :)

Os is Windows 7 64bit.

What I notice is that on the first upd, when fptest.exe does not exist everything runs correctly. If I change a source file and run upd again, fptest.exe will execute before the files are compiled/linked again.

Owner
gittup commented Dec 21, 2012

On Tue, Dec 18, 2012 at 5:07 AM, Joacim Jacobsson
notifications@github.comwrote:

DEFINES += /D_DEBUG
DEFINES += /DDEBUG
DEFINES += /D_CONSOLE
DEFINES += /D_CRT_SECURE_NO_WARNINGS
DEFINES += /D_UNICODE
DEFINES += /DUNICODE

CCFLAGS += /nologo
CCFLAGS += /c
CCFLAGS += /errorReport:prompt
CCFLAGS += /wd4530
CCFLAGS += /wd4305
CCFLAGS += /wd4244
CCFLAGS += /W3
CCFLAGS += /TP
CCFLAGS += /Od
CCFLAGS += /Z7

LINKFLAGS += /nologo
LINKFLAGS += /DEBUG
LINKFLAGS += /INCREMENTAL:NO
LINKFLAGS += /SUBSYSTEM:CONSOLE

!link_exe = |> ^ Linking %o^ link $(LINKFLAGS) %f /OUT:%o /PDB:%O.pdb |> %O.pdb %O.ilk
!cc = |> ^ Compiling %f^ cl %f $(CCFLAGS) $(DEFINES) /Fo%B.obj |> %B.obj

: foreach *.cpp |> !cc |> {objs}
: {objs} |> !link_exe |> fptest.exe
: fptest.exe |> ./fptest.exe |> image.jpg

That is my full Tupfile. And as you see I'm using Visual Studio :) Windows
7 64bit.

What I notice is that on the first upd, when fptest.exe does not exist
everything runs correctly. If I change a source file and run upd again,
fptest.exe will execute before the files are compiled/linked again.

Is your cl.exe itself 64-bit? Or is it generating 64-bit executables
somehow? I have win7-64 bit, but my cl.exe shows:

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for
80x86

And the fptest.exe I get looks like:

$ file fptest.exe
fptest.exe: PE32 executable (console) Intel 80386, for MS Windows

If yours is 64-bit, it's going to be the same issue that tup doesn't yet
work with 64-bit executables on Windows. If your cl.exe and fptest.exe show
up as 32-bit then something else must be going on...

Thanks,
-Mike

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