Build dependencies

[Nycto]

When I'm doing a local build, I prefer to keep my build directory free from build artifacts. It makes it easier for me to manage my git repo as I can stage my changes without having to worry about accidentally committing a build artifact. The current behavior of nimble is to create an artifact alongside the source file being compiled.

Would you be amendable to making this configurable somehow? I see a few options:

• As a property in the .nimble file for a project. This would mean anyone who builds the project would inherit this configuration, but that isn't necessarily a bad thing
• As a CLI arg. But this would require specifying it any time I did a build, which is inconvenient
• In the nimble.ini file. This would make it global, which I'm wary of.
• As an environment variable. Also a global change (or I would have to set it any time I started work)

Also, should the test target build to a different location than the bin target? And should they be separately configurable?

Cheers

[Araq]

Use a .gitignore?

[dom96]

This is already configurable via bin https://github.com/nim-lang/nimble#optional#

Also, should the test target build to a different location than the bin target? And should they be separately configurable?

I don't see a reason why this should be configurable. You can always write your own test target if you want, it can be overriden.

[Nycto]

Ah, thanks for the link!

I still think being able to define a scratch directory would be useful for the test target. Using .gitignore and creating a custom test target share the same problem: they push the implementation into each package rather than centralizing into a standard mechanism.

For .gitignore, I would either need to add an exclusion for each test file that gets added, or add (what I think) is an overly broad rule to exclude files without an extension.

For the test target, nimble doesn't currently have a great way of handling build-only dependencies. So I would need to copy the implementation into all the nim repos I've got. (I would also be in favor, btw, of solving this request by supporting build-only dependencies)

And from a purist perspective, I also think mixing your source and build artifacts is a bad practice. I want to be able to tell you where to put things so I don't have to worry about anything intermingling.

[dom96]

For the test target, nimble doesn't currently have a great way of handling build-only dependencies. So I would need to copy the implementation into all the nim repos I've got. (I would also be in favor, btw, of solving this request by supporting build-only dependencies)

Hrm, can you elaborate, I'm not sure how build-only dependencies relate to build artefacts.

I'm also curious where you would like the test build artefacts to go?

[Nycto]

Bear with me here. I may be projecting preconceived concepts from other build systems that may or may not apply here. Let me apologize up front if that is the case. That said...

Hrm, can you elaborate, I'm not sure how build-only dependencies relate to build artifacts.

Your suggestion was to write my own test target. But, currently, I've got 10+ Nim projects if you count all my public and private repos. Which means I've got 10+ nimble files to manage. Rather than copying the same code into each nimble file, I would like to be able to centralize it into a single repo that I can then include from all the other nimble files.

To achieve this, though, I would need to declare a dependency that only gets used by the build. Any downstream projects that happen to consume my lib don't need to pull in that dependency. This is akin to dependency scope in Maven, for example.

I'm also curious where you would like the test build artefacts to go?

I personally like to drop things in a .build directory. So my structure winds up looking like this:

src/...
tests/...
foo.nimble
.build/nimcache/...
.build/bin/...
.build/tests/...

[dom96]

Ahh, that's what you mean. Indeed, that is a planned feature. I'm not sure "build dependency" is the right term for it though, when your package is used it is technically built by another package.

[dom96]

This will be handled by #482.