Comments (6)
This is on purpose, at least so far. I'm not sure what to do about it. reggae is like cmake in which you're encouraged to build out-of-source so the targetPath should be whatever the build directory is.
from reggae.
I'm not sure what to do about it.
I think this feature is most useful in the context of the root project that is being build by dub. As far as dependencies of the root project are concerned, it doesn't really matter where their build artifacts are placed, as expectation of most people is that the build system "takes care of them", so whether you honor targetPath
of dependencies or put them in /tmp/build-$uuid
it doesn't matter for most applications. What would be useful is to either keep the concept of dub global (per user) cache and put the build artifact of each dependency in $HOME/.dub/packages/package-version/package)
or have a per-project/per-build
build folder (that includes the current project and all of it's dependencies).
As far as the root project is concerned, targetPath
is basically the analog of install prefix for Makefiles, only relative to project folder and not the the file system root.
In practice, I have set a targetPath
to ./build/[config]
all of my dub projects as:
- I don't want build artifact polluting my root folder
- I need the build artifacts to be placed in a predictable location for CI/CD, Docker build, etc.
- A few years ago, when I was still working on Windows at times, I used open the same project folder in WSL and Windows cygwin/msys2/Batch Command Prompt terminal simultaneously and I would run Dub for Windows and Linux in parallel. On Windows I also used to test with both -m32 and -m64. Because of that I used
./build/{Linux, Win}{x86, x86_64}
as targetPath, so I could work with different dub build configurations in parallel.
from reggae.
reggae is like cmake in which you're encouraged to build out-of-source so the targetPath should be whatever the build directory is.
I think you may be confusing the concepts:
- build dir ->
$package/.dub
- this is not configurable, as far as I know and as such reggae can do whatever it likes. - install dir ->
targetPath
indub.{sdl,json}
- this is what we want reggae to respect. You can implement it by simply copying the target files to this location as a final build step.
from reggae.
targetPath
is the path where the target gets emitted. When one has a build directory for that purpose, it doesn't seem to make much sense to add a subdirectory to that. I usually have targetPath
set to bin
and usually run reggae from bin
. I don't want binaries in bin/bin
. But I understand that people would like to run reggae from the root path and have targetPath respected.
I guess... use targetPath iff run from root?
I don't know what installation has anything to do with this.
from reggae.
targetPath is the path where the target gets emitted.
Not necessarily. The target can be emitted in $TMP
, build/
, .dub
, where exactly doesn't matter as far as the user is concerned. As a user I only care that it's copied to the targetPath
, relative to dub.{sdl,json}
after the build is finished.
When one has a build directory for that purpose, it doesn't seem to make much sense to add a subdirectory to that. I usually have targetPath set to bin and usually run reggae from bin. I don't want binaries in bin/bin.
I think it's best to consider the build directory and the targetPath as two completely unrelated paths. As such, the build directory can be $DUB_ROOT_DIR/build
and the targetPath is $DUB_ROOT_DIR/$targetPath
.
I guess... use targetPath iff run from root?
In general I think yes, though in theory some dependencies could rely on targetPath to be respected, though I can't imagine a reasonable use case.
I don't know what installation has anything to do with this.
Just like running ninja install
after building say LLVM will copy the target outputs to CMAKE_INSTALL_PREFIX
, dub build
will copy the target output of the root project to targetPath
. It's not a perfect analogy since CMAKE_INSTALL_PREFIX
can set to /
and as such modify the system directories, which is something that IIRC Sonke has been opposed against.
from reggae.
As a user I only care that it's copied to the targetPath, relative to dub.{sdl,json} after the build is finished
That's the same as creating it there in the first place. I don't think its simultaneous existence elsewhere matters much.
I think it's best to consider the build directory and the targetPath as two completely unrelated paths. As such, the build directory can be $DUB_ROOT_DIR/build and the targetPath is $DUB_ROOT_DIR/$targetPath.
We're talking about reggae here. The build path is wherever reggae is run from. This is by design.
in theory some dependencies could rely on targetPath to be respected, though I can't imagine a reasonable use case.
Given how reggae works, I can't see how. Especially since it's the one building the dependencies as well.
ust like running ninja install after building say LLVM will copy the target outputs to CMAKE_INSTALL_PREFIX, dub build will copy the target output of the root project to targetPath.
These two are not the same thing. The only similarity is that dub copies (on Windows, on Linux it at least was a hard link) a binary from one place to the other. There's no dub install
, nor should there be in a world of package managers.
from reggae.
Related Issues (20)
- dub copyFiles with relative globs doesn't work in dependencies HOT 1
- Compilation Error: "slice [1 .. 0] has a larger lower index than upper index" HOT 4
- dubConfigurationTarget doesn't work HOT 2
- dubDependant should propagate flags (especially version flags) from the dependencies upwards
- dubDependant should propagate flags (especially version flags) from the dependencies downwards
- Propagate command-line options passed to reggae to dub dependencies such as `--dub-objs-dir`
- JSON compilation database support
- Error: cannot take address HOT 2
- Run dub prebuild commands at build time, not reggae time
- Request for Help - Configuring Reggae without dub.sdl HOT 4
- When a common import has an error, ninja's output is very verbose HOT 5
- Get rid of `dub build` when building the reggaefile
- Add options to the binary backend for reggaefile build: threading and build type
- dub preBuildCommands should be run as part of the build, not at reggae time
- Files with C extensions should be automatically included
- Deleting source files results in reggae rerun failing HOT 1
- compile_commands.json breaks when paths contain spaces HOT 3
- .dep file issues with buildgen HOT 1
- The dubPackage/dubDependant rules should trigger a rerun if the recipe is changed
- compile_command.json contain invalid escape sequences HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from reggae.