development: make it possible to run NetworkManager from build directory #52
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It used to be possible to successfully run NetworkManager from the build directory at least using `--run-from-build-dir`. The code is relatively complicated for that simple task and doesn't even achieve the results. For example the path to device plugins is hardcoded and the actual device plugins are in their own different build directories. There is no trivial way to fix that. In future we should probably implement running from build directory using a set of environment variables with search paths and other tweaks together with `NetworkManager` and `nmcli` shell wrappers that would make it all work. In addition to plugin and helper search paths there appears to be a problem with the dbus and polkit configurations in the running system. This seems to be a drawback related to the usage of D-Bus for all communication.
In some cases we might want to load device plugins from multiple directories. A special case that I have in mind is to load plugins from build directory subdirectories in order to run NetworkManager from the build directory.
Many of the configured directories default to being defined using existing directory configuration. As a result you usually don't see the actual directories that will be used. With the added directories you can at least assemble the information and thus see which directories will be used.
The combination of `./develop.sh` for bootstrap and configuration and the `./NetworkManager` and `./nmcli` makes it easy to build NetworkManager and then run it from the build directory.
Collaborator
|
I merged two patches from the branch to master (96658d2). There are two patches left:
I am not convinced about a compile time option. Changing a configure option is cumbersome, because it requires rebuild most of the code. Also, you effectively cannot
|
Collaborator
|
As I said, I think the remaining two patches need some rework. I am closing this pull request for now, please re-open, if there is anything new. Thank you! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I know we were talking about keeping the
NetworkManager --run-from-build-diroption but right now it feels much easier to just use./autogen.sh --enable-developand have the feature cleanly applied just to the development build and nowhere else.This way we can try to keep devel builds safe from loading system NetworkManager libraries and plugins and at the same time the system build doesn't get polluted by code that only applies to the build directory.
I propose to merge this pull request now because it's extremely useful to have the feature in master and thus be able to build branches in develop mode immediately. We can reconsider the approach later if needed.