dub
dub copied to clipboard
how to specify where to output library/executable?
eg:
could there be options output_file and output_dir?
cd ~/.dub/packages/libdparse-master
dub build --compiler=ldc2 --output_file=libdparse.ldc.a
dub build --compiler=dmd --output_file=libdparse.dmd.a
or:
dub build --compiler=dmd --output_dir=./dmd_build => will build in ./dmd_build/libdparse.a
You can specify in dub.sdl
targetPath "./dmd_build"
This works but requires manually editing the sdl file; Could those --targetPath --targetName be exposed in the command line?
This would be useful, eg, for automating building via dub with different configurations (ldc,dmd)
This is a common use case.
Sounds like a good idea.
Today I also stumbled over this issue. Use case: I want to create a Docker container which contains only D-Scanner executable. Therefore I use a multi stage Dockerfile. In first stage I fetch and build scanner and in second stage I copy the executable.
But the hard part is to get the path to the executable. Maybe it is somehow possible using dub describe with target-path and target-name ( the values are separated by a NUL character)
It is possible but for an inexperienced user it is unnecessary hard.
If I could set the executable path in dub build command this would be really elegant
Another use case from @adamdruppe https://forum.dlang.org/post/[email protected]
Yeah, this would be a big help to me. I tried to implement myself but couldn't follow the code flow... my attempt kept getting overwritten by later loading of the config file :(
It just came to my mind, it isn't as easy as thought. A dub package can produce multiple outputs (by using dub sub packages and setting main package to type none). Should the new argument only support setting output path for main dub package or also for the sub packages?
On Wed, Jan 01, 2020 at 06:24:24AM -0800, andre2007 wrote:
Should the new argument only support setting output path for main dub package or also for the sub packages?
In my case, it is only the main package I want there.
Could perhaps be several separate options if we need the others to change too.
I would like this as well.
Implemented that on redub, and here's what I've done:
The main requirement hash does not account anymore for the project name or the target path. But the project cache actually accounts for it, so it will be able to reuse all other already compiled packages.
Subpackages aren't important on that aspect, if someone wants them in the output path, they simply should use copyFiles. This serves at least for the main output path.
I've also put targetName, which is a feature that I wished that existed on dub. It is important to rebuild the main project since, at least on windows, their target name is hardcoded inside the .pdb files, which makes it harder to use when you want to hotreload and want to get debug information