Output path for artifacts generated by ghdl --bind

[eine]

Coming from gitter:

[@1138-4eb]
While using ghdl --bind I saw that '--workdir' does have no efect on the output path of the artifacts. For example:

ghdl --bind -fPIC --std=08 --workdir=./build/obj test_demo

The command above will find test_demo in ./build/obj, because the corresponding VHDL file was analysed with ghdl -a -fPIC --std=08 --workdir=./build/obj test_demo.vhd. However, e~test_demo.lst and e~test_demo.o are created in the current dir. I would expect them to be created in --workdir. According to the docs: The object files created by the compiler are always placed in the same directory as the WORK library. Is this a bug or the expected behaviour?

[@tgingold]
This is the expected behaviour (maybe not well documented): the final executable is created in the current working directory.

[@1138-4eb]
I see... these e~* files are handled as final executables instead of intermediate objects. Would it be possible to optionally set the output dir? I can imagine that this has some effect on --list-link too, so it might not be straighforward. If so, please just let me know and I will work arount it with cd and sed (as in #640). But, if possible, I think it'd be useful to be able to call GHDL without producing artifacts in the current dir.

[@tgingold]
You can always cd to the destination directory and create the executable here (adjusting -P and --workdir= options).

---

The point is that I am not creating any executable with GHDL; instead, I am building objects that will be later built in a third-party tool:

• Analyze VHDL sources with ghdl -a --workdir=build/obj ...
• Bind the unit with ghdl --bind --workdir=build/obj ...
• Generate the list of arguments with ghdl --list-list ... and save it to a list_file.txt.
• Manipulate the file with sed to make paths portable.
• Save objects and list_file.txt in a tarball.

Then:

• Get the sources of a third-party toool, where we want to integrate GHDL by including all the objects and calling ghdl_main.
• Extract the tarball.
• Executing gcc <app-specific args> -o build/bin/app $(cat lis_file.txt) (or the equivalent with g++/cmake).

As you see, the executable is generated in the very last step, and I can locate it wherever with option -o. However, in the steps above I am left with objects generated by GHDL in various locations (which are all different from where the target binary is located):

• /usr/local/lib.
• --workdir.
• ./ where ghdl --bind was executed.

Ideally, ghdl --bind would generate any object except executable binaries in --workdir.

NOTE: Note that all of the steps above are not being executed neither by hand nor through a shell script; golang is being used. Furthermore the golang script/binary can be executed either natively or inside a container. When inside a container, GHDL can be spawned in the came context or in a sibling container. As a result, playing with the path and the workdir can be error prone. So, if possible, I'd like to avoid it.

Overall, it seems that the safest approach ATM is to avoid --workdir at all. I.e., cd to build/obj and execute ghdl -a, ghdl --bind and ghdl --list-link there; as using --workdir is not useful at avoiding the requirement to cd later.

Should we add a comment at https://ghdl.readthedocs.io/en/latest/references/CommandReference.html#bind-bind or https://ghdl.readthedocs.io/en/latest/references/ImplementationOfVHDL.html#linking-with-ada?

BTW, I am thinking about renaming section 'Linking with Ada' to 'Linking with Ada or C', since the process is the same for both.

[eine]

A little update: ghdl --bind accepts -o path/name, so it is possible to generate e~name.lst and e~name.o anywhere. However, ghdl --list-link name will only look for e~name.lst in the current directory.

[tgingold]

So a possible enhancement is to add a new option to list-link to specify path/name

[eine]

So a possible enhancement is to add a new option to list-link to specify path/name

Yes. But ghdl --bind might need to be modified too:

Currently, ghdl --bind -o path/name primary_unit secondary_unit will generate path/e~name.o and path/e~name.lst. So, ghdl --list-link [-p path/name] primary_unit secondary_unit would be required. It is a bit dirty, because almost all of the users will need ghdl --bind -o path/primary_unit primary_unit secondary_unit and ghdl --list-link -p path/primary_unit primary_unit secondary_unit.

I think it should be ghdl --bind [-o path] primary_unit secondary_unit and ghdl --list-link [-p path] primary_unit secondary_unit. I.e. -o and -p do not define the name of the file (which is derived from primary_unit), they just provide the path.

Or, even better, ghdl --bind [path/]primary_unit secondary_unit and ghdl --list-link [path/]primary_unit secondary_unit. The syntax is not modified, but GHDL is adapted to optionally parse a path from the primary_unit argument. In this case, option -o should be deprecated for --bind.

What do you think?