Hello,
The name of certain output files depends on the toolchain in use; for
example, objects may be .o or .obj. When these variable-name output files
are, in turn, input by some commands, the need arises to be able to refer
to them. I use groups for this (see this question
<https://groups.google.com/d/topic/tup-users/4hT8sYtXKT8/discussion>.
Thanks Freddie!):
# /libs/Tupfile
# can build any type of library:
: object1.o object2.o |> gcc-ar rcs %o %f |> mylibrary.a <mylibrary>
: object1.o object2.o |> gcc -shared -o %o %f |> mylibrary.so <mylibrary>
: object1.o object2.o |> gcc-ar rcs %o %f |>
I_change_the_extension_because_I_feel_like_it.rocks <mylibrary>
# /Tupfile
: main.o libs/<mylibrary> |> gcc -o %o %f |> main
However, things get harder when building DLLs, on Windows, as the linker
not only produces the DLL, but also an import library (.lib) and an export
definition file (.exp). Unlike in Linux, applications don't link to DLLs
(in fact, the linker isn't able to and complains that the DLL is an invalid
or corrupt file) but to their companion import libraries, which contain the
code to load ('import') the DLLs at runtime. Now, the previous approach
doesn't work, because the three output files will go into the group,
whereas only one should (the .lib):
# /libs/Tupfile
# No way to exclude mylibrary.dll and mylibrary.exp from the output group
: object1.obj object2.obj |> link.exe -out:mylibrary.dll -dll -implib:
mylibrary.lib %f |> mylibrary.dll mylibrary.lib mylibrary.exp <mylibrary>
# /Tupfile
: main.obj libs/<mylibrary> |> cl.exe /o %o %f <mylibrary> |> main.exe
# expands to: cl.exe /o main.exe main.obj libs/mylibrary.dll
libs/mylibrary.lib libs/mylibrary.exp
# should be : cl.exe /o main.exe main.obj libs/mylibrary.lib
It is possible to build the import library in a separate step (see this page
<https://msdn.microsoft.com/en-us/library/0b9xe492.aspx>), but this command
also produces an .exp file. I don't know of any command that only produces
the import library (I'm not familiar with the MSVC toolchain).
My current workaround is:
# Rumour has it the one who wrote this hacky rule, consumed by guilt, soon
committed suicide
: mylibrary.lib |> cp -- %f %o |> copyof-%f <mylibrary>
Needless to say, I cannot sleep with this impious sacrilege in my
conscience.
Other hacky workarounds come to mind. For example, the output file name
could be written to an invariable-name file (say, mylibrary.name). In fact,
I already do this so that the installation script knows which files to
install, so I could just reuse these .name files. But it's ugly, and it
would require to use a shell to read those .name files.
FWIW, I'm using the Lua parser, but variables aren't shared between
Tupfile.luas.
I just want to stay portable across toolchains.
What are your thoughts on this?
P.S.: I write these rather lengthy explanations in the hope that they'll
help you understand why I need to do this and, perhaps, make you able to
tell me a better solution, if I have fallen in an "XY problem". I hope this
doesn't end up being worse.
--
--
tup-users mailing list
email: [email protected]
unsubscribe: [email protected]
options: http://groups.google.com/group/tup-users?hl=en
---
You received this message because you are subscribed to the Google Groups
"tup-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
