dune build should build current directory's package, not entire dune project

[mimoo]

When I'm in a specific folder in my dune project, I expect dune build to only build the package in that folder (that has a dune file)

$ pwd
/Users/davidwong/Work/mina_nix/src/lib/pickles

$ dune build
Entering directory '/Users/davidwong/Work/mina_nix'
...

The messages displayed seem to indicate that everything is being built.

I guess I would expect the same behavior with dune runtest

[rgrinberg]

Yes, because dune build is short for dune build @all. If you only want to build a particular package, you may just build $ dune build $pkg.install

[mimoo]

I think that's a bit unintuitive. There's also no way I'll be able to remember how to build a specific package : o

[rgrinberg]

The old behavior dune has similar to what you suggested. Users claimed it was also confusing because it wouldn't build anything without it being attached to a package. Rudi.

…

On Oct 24, 2022, 9:52 AM -0600, David Wong ***@***.***>, wrote: I think that's a bit unintuitive. There's also no way I'll be able to remember how to build a specific package : o — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[mimoo]

I guess this issue could be about having a more intuitive command to build the package in the current folder :o

perhaps dune build . ?

[rgrinberg]

The "package in the current folder" isn't an intuitive concept. There might be 0, 1, or many packages in the same folder. Rudi.

…

On Oct 24, 2022, 9:57 AM -0600, David Wong ***@***.***>, wrote: I guess this issue could be about having a more intuitive command to build the package in the current folder :o — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[mimoo]

btw this is what cargo would do for reference, which I find very user-friendly:

• dune build . would build all of the packages at the location (so it doesn't matter if there's 0, 1, or more)
• dune exec . would tell the user: "there are several targets: ..." and list the target names with the relevant command (e.g. dune exec ./target) so that the user can retry

[rgrinberg]

That's funny, because I find your proposal to be unfriendly. Perhaps it's a question of familiarity? Or maybe cargo does not allow targets to exist outside of packages. There's also dune build @install, which will build all the packages when it's in the root of the repo. I don't remember if it works in sub directories, but it could be worth fixing that if it doesn't. Improving the error of dune exec would certainly be a nice thing to do. Rudi.

…

On Oct 24, 2022, 10:02 AM -0600, David Wong ***@***.***>, wrote: btw this is what cargo would do for reference, which I find very user-friendly: • dune build . would build all of the packages at the location (so it doesn't matter if there's 0, 1, or more) • dune exec . would tell the user: "there are several targets: ..." and list the target names with the relevant command (e.g. dune exec ./target) so that the user can retry — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[mimoo]

Or maybe cargo does not allow targets to exist outside of packages.

What do you mean by this?

[rgrinberg]

What's the equivalent of an executable that does not belong to any package in cargo? In dune that would be: (executable  (name foo)) How do you define and build such a target in cargo? Rudi.

…

On Oct 24, 2022, 10:14 AM -0600, David Wong ***@***.***>, wrote: > Or maybe cargo does not allow targets to exist outside of packages. What do you mean by this? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[mimoo]

In cargo your stuff (library or binary (execute)) is always part of one package (declared via the Cargo.toml file which is somewhat equivalent to a dune file here).

Isn't it true for dune as well? Here you would define that executable in a dune file which would be next to a dune-project file which would have the package name?

EDIT: I guess it doesn't work like this. I'm always confused as to what exactly is a package when you start playing with both dune and opam. I was under the impression that a dune file = one package, and then you can have multiple subpackages or executables listed in there

[rgrinberg]

In my example, the executable does not belong to any package because it doesn't have a public_name nor a package field. I guess this is the source of friction. In dune, targets (such as libraries or executables) can stay unattached to any package. Such targets are deemed "private" in dune. Rudi.

…

On Oct 24, 2022, 10:19 AM -0600, David Wong ***@***.***>, wrote: In cargo your stuff (library or binary (execute)) is always part of a package. Isn't it true for dune as well? Here you would define that executable in a dune file which would be next to a dune-project file which would have the package name? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[mimoo]

I see, but so why would it be unfriendly to build all such targets when doing a dune build .?

[rgrinberg]

What do you mean it's unfriendly? The current behavior of `$ dune build .` is already to build all targets in the current directory. Therefore it would pick up the executable as well. Or do you expect it should also pick up executables in sub directories as well? Rudi.

…

On Oct 24, 2022, 10:26 AM -0600, David Wong ***@***.***>, wrote: I see, but so why would it be unfriendly to build all such targets when doing a dune build .? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[mimoo]

Oh I was reacting to your comment:

That's funny, because I find your proposal to be unfriendly

But maybe I misunderstood what you found unfriendly?

Or do you expect it should also pick up executables in sub directories as well?

I would expect that yeah (I understand that dune seems to have vague conventions regarding directory structure though). But to me dune build . should build everything it can find under the pointed location (recursively).

[mimoo]

(same for dune runtest . btw, I want to test if all tests run under some directory structure when I do this)

[rgrinberg]

I don't know cargo very well, but I do find it strange that everything must exist as part of a package. I find targets that don't belong to any packages and are therefore hidden from users of the package to be a useful feature. Making `dune build .` recursive is something that is up to debate. It doesn't seem like a bad idea to me at first. For now, you can just do `dune build` as alternative, or `dune build @all` if you want to be more explicit. `dune runtest .` already works in exactly the way you describe. Rudi.

…

On Oct 24, 2022, 10:40 AM -0600, David Wong ***@***.***>, wrote: Oh I was reacting to your comment: > That's funny, because I find your proposal to be unfriendly But maybe I misunderstood what you found unfriendly? > Or do you expect it should also pick up executables in sub directories as well? I would expect that yeah. (I understand that dune seems to have vague conventions regarding directory structure though) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[mimoo]

I find targets that don't belong to any packages and are therefore hidden from users of the package to be a useful feature.

I think the design of cargo is really to use as much convention as possible to avoid configuration (which I think is the way to go personally). The way you would do that for libraries, is to simply not add the pub keyword to your types/functions/modules in Rust. Everything is private by default (unlike OCaml where everything is public by default). I don't think you can have private binaries/executables, but then why would you make any of them private? The only reason someone would try to use these executable is to work on the library, and thus they most likely need access to the executables.

For now, you can just do dune build as alternative, or dune build @all if you want to be more explicit.

I still have the problem that this tries to build the entire dune-project and dune files that are parent to the folder I'm in, IIUC

[rgrinberg]

When somone is working on a library, the executable is certainly available. The executable is only unavailable to those that consume the package via opam. A simple use case is code generators. For example, you might want to create a code generator and use it to auto-generate some library code (bindings for example). Such an executable is clearly an implementation detail of the generated bindings and shouldn't be available to end users of your library. I would like to reduce the amount of configuration dune requires. So please share if you have any concrete ideas you might have. I suggest that you get familiar with dune first though. To understand why we can't just copy cargo in some situations. Rudi.

…

On Oct 24, 2022, 10:59 AM -0600, David Wong ***@***.***>, wrote: > I find targets that don't belong to any packages and are therefore hidden from users of the package to be a useful feature. I think the design of cargo is really to use as much convention as possible to avoid configuration (which I think is the way to go personally). The way you would do that for libraries, is to simply not add the pub keyword to your types/functions/modules in Rust. Everything is private by default (unlike OCaml where everything is public by default). I don't think you can have private binaries/executables, but then why would you make any of them private? The only reason someone would try to use these executable is to work on the library, and thus they most likely need access to the executables. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[mimoo]

The executable is only unavailable to those that consume the package via opam

I think I understand what you're saying. In cargo you do not have access to any executables of a dependency you list in your project (IIRC).

For example, you might want to create a code generator and use it to auto-generate some library code (bindings for example). Such an executable is clearly an implementation detail of the generated bindings and shouldn't be available to end users of your library

BTW, perhaps this is useful, but cargo works by detecting a build.rs file in the root of your project, and running it first when building. It is usually used to generate code needed for the library to run correctly.

I would like to reduce the amount of configuration dune requires. So please share if you have any concrete ideas you might have. I suggest that you get familiar with dune first though. To understand why we can't just copy cargo in some situations.

I think at this point I've read the whole doc and battled with it quite a lot :D but I haven't looked at the code of dune itself. I'm wondering if it would make sense to start from scratch as going for a convention over configuration approach would probably mean too many breaking changes :o

[rgrinberg]

Starting a new build system from scratch? Good luck :)

Introducing new conventions to dune isn't a problem as long as we still support the old ones. We're quite strict with backwards compatibility.

[mimoo]

Starting a new build system from scratch? Good luck :)

yeah I was wondering how much work there is in there :D

I don't think dune could become a tool like cargo while remaining backward compatible. Perhaps a number of libraries in dune can be reused for that purpose though?

[rgrinberg]

Well, I'm not going to discourage you :) Rudi.

…

On Oct 24, 2022, 12:19 PM -0600, David Wong ***@***.***>, wrote: > Starting a new build system from scratch? Good luck :) yeah I was wondering how much work there is in there :D — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>