Giter Site home page Giter Site logo

dub: `targetPath` is ignored about reggae HOT 6 CLOSED

kinke avatar kinke commented on June 10, 2024
dub: `targetPath` is ignored

from reggae.

Comments (6)

atilaneves avatar atilaneves commented on June 10, 2024

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.

PetarKirov avatar PetarKirov commented on June 10, 2024

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.

PetarKirov avatar PetarKirov commented on June 10, 2024

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.

from reggae.

atilaneves avatar atilaneves commented on June 10, 2024

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.

PetarKirov avatar PetarKirov commented on June 10, 2024

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.

atilaneves avatar atilaneves commented on June 10, 2024

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)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.