atilaneves / reggae

Build system in D, Python, Ruby, Javascript or Lua

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

dub: `targetPath` is ignored

kinke opened this issue · comments

targetName works fine, but specifying the output dir via targetPath has no effect.

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.

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.

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 in dub.{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.

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.

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.

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.