search

nim-lang / nimble

Package manager for the Nim programming language.
https://nim-lang.github.io/nimble/index.html
Other
1.25k stars 191 forks source link

Add os/arch options to .nimble? #764

Open coolreader18 opened 4 years ago

coolreader18 commented 4 years ago

When compiling for an embedded platform like raspberry pi, microprocessors, nintendo switch, or graphing calculators, you usually never want to build for your host machine but rather a specific os/arch tuple, and it can be annoying to always have to pass --os:_ --arch:_ to nimble build. Maybe there could be os and arch options in .nimble, similar to backend?

SolitudeSF commented 4 years ago

there is nim.cfg and others for compiler options

coolreader18 commented 4 years ago

That doesn't work when there's configuration in the global nim.cfg that looks at os and arch, e.g. raspberry pi. If it's in .nimble, it also makes it part of the project's metadata; it's clear that a project is intended to be compiled for a specific platform.

coolreader18 commented 4 years ago

I could work on an implementation of this if people think it's a good idea.

Araq commented 4 years ago

I think it is a good idea.

genotrance commented 4 years ago

The way I understand this is that nim.cfg changes are loaded in global to project to local folder order and there's no way to affect previously loaded values from later cfg files. The only way today is to use the Nim command line options which get loaded first.

Nimble passes command line options to Nim which might appear to be a place where this can be solved but I'd rather ask if it can be solved within the compiler itself. Maybe a --cli option which informs Nim to include that in the CLI and reprocess all cfg files.

This way, other methods of building Nim projects can also benefit. Further, we are looking at ways of leveraging nim.cfg more within Nimble and so this change would be counter to that.

cc @disruptek

disruptek commented 4 years ago

The convention we decided upon was that nim.cfg is used to adjust settings using the compiler's usual traversal, eg. nim processes each nim.cfg it finds in the tree; proceeding from the project directory upwards the compiler enumerates from the project up, but processes the configs from the root down. This does allow you to override global or parent compiler settings.

Further, the assumption is that, at least in the case of a nim.cfg in the project directory, the nim.cfg may be edited or even deleted by the package manager in order to control the particulars of the site's configuration -- think local dependencies, paths, and so on. Such a nim.cfg should not be in your repository, as this could confuse the package manager; I'm being vague because the circumstances in which it matters aren't terribly interesting or relevant.

The configuration file you probably want to use for these settings is someproject.nim.cfg, which the package managers won't fool with, but which will nonetheless get picked up and used by the compiler. This is a file suitable for inclusion in your vcs and distributed to users, etc.

genotrance commented 4 years ago

@disruptek - the point is that adding flags in a project local cfg does not affect how the global nim.cfg got processed. Only way today is to use the CLI since it happens first.

E.g. adding -d:mingw in someproject.nim.cfg will not reprocess this if condition.

samdmarshall commented 4 years ago

i assume this would also include limitations for OS specific pieces of software? like if the package is built around interacting with a single platform specific API (ex: winim), will there be a way to codify that beyond just having the build fail cuz it cannot find or link the necessary files (?)