Suppressing a plus from setlocalversion
Hello!
There is one annoyance in the build system that I cannot work around. Before I attempt hacking the code, I'd like to make sure I'm not missing anything obvious.
Suppose that I have a kernel version 3.1-rc2. I want to test some patch for some code that is compiled as a module. I change the code and create a patch with STGit. I recompile the modules, install them by "make module_install", unload the module I patched, load it again and find that there is no effect from my change. It turns out that the modules were installed to "/lib/modules/3.1.0-rc2+" and the plus was added by scripts/localversion because the source tree is now modified.
So I recompile the whole kernel, reboot and continue working on my patch. Many days later, I'm about to send my patch, but I want to retest the system without it, so I "stg pop" it, recompile the module, install it and find that the unpatched module behaves just like the patched one. Of course, it turns out that the unpatched module ended up in "/lib/modules/3.1.0-rc2", whereas modprobe keeps loading the modified module from "/lib/modules/3.1.0-rc2+"
CONFIG_LOCALVERSION_AUTO is unset, but that doesn't stop scripts/localversion from adding the plus. Setting CONFIG_LOCALVERSION doesn't help. Setting LOCALVERSION on the make command line helps, but it needs to be done every time, and it's too easy to forget. I don't want to write a wrapper around make, it would be too intrusive (actually, it's my solution for now).
Adding anything to localversion* doesn't suppress the plus. Keeping some patch in STGit all the time is quite annoying, I'll eventually end up sending it to some mailing list by mistake. STGit cannot hide applied patches. Besides, I'll need to be aware of the patch when switching branches.
File .scmversion is only read from the source directory, so having it is equivalent to having a modified source all the time, which is what I'm trying to avoid. Sure, I can keep .scmversion not in git, but I risk to clean it up with "git clean" eventually.
If there is no simple solution with the existing code, maybe non-empty CONFIG_LOCALVERSION should suppress the plus just like LOCALVERSION?
Or maybe CONFIG_LOCALVERSION_AUTO should be not yes/no, but full/minimal/no?
Signature · 2 lines
Regards, Pavel Roskin
Quoted 3 lines · Pavel Roskin
Hello!
There is one annoyance in the build system that I cannot work around.
That's surprising since you actually state the workaround, i.e. using LOCALVERSION= with make, yourself.
Quoted 11 lines
Before I attempt hacking the code, I'd like to make sure I'm not missing anything obvious.
Suppose that I have a kernel version 3.1-rc2. I want to test some patch for some code that is compiled as a module. I change the code and create a patch with STGit. I recompile the modules, install them by "make
module_install", unload the module I patched, load it again and find that there is no effect from my change. It turns out that the modules were installed to "/lib/modules/3.1.0-rc2+" and the plus was added byscripts/localversionbecause the source tree is now modified.
Yes, because the kernel you've produced is no longer 3.1.0-rc2, it is modified. If you want to do something else locally, then you can always use LOCALVERSION=.
The + was added to stop falsely identifying kernels as a specific version when they are modified by default. Sorry if you forget to override it sometimes.
Quoting David Rientjes <[email protected]>:
Quoted 8 lines · Pavel Roskin
Quoted 4 lines
Hello!
There is one annoyance in the build system that I cannot work around.
That's surprising since you actually state the workaround, i.e. using LOCALVERSION= with make, yourself.
OK, I don't consider that an acceptable solution, as it could interfere with other build systems.
However, as soon as I posted this message, I found a better solution, namely setting LOCALVERSION= in the environment (both for the normal user and for root). This is less likely to have unexpected effects, since the environment variables don't override the variables explicitly set in makefiles.
Quoted 7 lines
Yes, because the kernel you've produced is no longer 3.1.0-rc2, it is modified. If you want to do something else locally, then you can always use LOCALVERSION=.
The + was added to stop falsely identifying kernels as a specific version when they are modified by default. Sorry if you forget to override it sometimes.
OK, I have an acceptable solution for my needs now, and if others need it, hopefully they would find this post.
Signature · 2 lines
Regards, Pavel Roskin
Quoted 11 lines · On Aug 15 Pavel Roskin wrote:
Quoting David Rientjes <[email protected]>:
Quoted 8 lines · Pavel Roskin
Quoted 4 lines
Hello!
There is one annoyance in the build system that I cannot work around.
That's surprising since you actually state the workaround, i.e. using LOCALVERSION= with make, yourself.
Quoted 8 lines
OK, I don't consider that an acceptable solution, as it could interfere with other build systems.
However, as soon as I posted this message, I found a better solution, namely setting LOCALVERSION= in the environment (both for the normal user and for root). This is less likely to have unexpected effects, since the environment variables don't override the variables explicitly set in makefiles.
Having this globally as an environment variable seems to be a more intrusive alternative; there are no namespaces.
You can wrap the make command lines that you often use into shell aliases. I often use command lines like 'nice make -j8' or 'nice make -j8 C=1 CF="-D__CHECK_ENDIAN__"' by alias.
Quoted 7 lines
Quoted 7 lines
Yes, because the kernel you've produced is no longer 3.1.0-rc2, it is modified. If you want to do something else locally, then you can always use LOCALVERSION=.
The + was added to stop falsely identifying kernels as a specific version when they are modified by default. Sorry if you forget to override it sometimes.
I for one am glad that I don't have to remember to force a localversion all the time. All of the kernels that I runtime-test have their source managed by quilt, not git. Thankfully, scripts/setlocalversion acknowledges that quilt users know what they are doing. :-)
Signature · 3 lines
Stefan Richter -=====-==-== =--- =---- http://arcgraph.de/sr/
Quoting Stefan Richter <[email protected]>:
Quoted 15 lines · On Aug 15 Pavel Roskin wrote:
Quoted 14 lines
Quoting David Rientjes <[email protected]>:
Quoted 8 lines · Pavel Roskin
Quoted 4 lines
Hello!
There is one annoyance in the build system that I cannot work around.
That's surprising since you actually state the workaround, i.e. using LOCALVERSION= with make, yourself.
OK, I don't consider that an acceptable solution, as it could interfere with other build systems.
Quoted 8 lines
Quoted 5 lines
However, as soon as I posted this message, I found a better solution, namely setting LOCALVERSION= in the environment (both for the normal user and for root). This is less likely to have unexpected effects, since the environment variables don't override the variables explicitly set in makefiles.
Having this globally as an environment variable seems to be a more intrusive alternative; there are no namespaces.
I know, it's not an ideal solution.
Quoted 3 lines
You can wrap the make command lines that you often use into shell aliases. I often use command lines like 'nice make -j8' or 'nice make -j8 C=1 CF="-D__CHECK_ENDIAN__"' by alias.
__CHECK_ENDIAN__ is addressed by a separate patch :)
I guess I need to write a wrapper that would be suitable for my needs.
Still, I'd prefer the build system do what I want, at least in some
aspects.
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Yes, because the kernel you've produced is no longer 3.1.0-rc2, it is modified. If you want to do something else locally, then you can always use LOCALVERSION=.
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
The + was added to stop falsely identifying kernels as a specific version when they are modified by default. Sorry if you forget to override it sometimes.
I for one am glad that I don't have to remember to force a localversion all the time. All of the kernels that I runtime-test have their source managed by quilt, not git. Thankfully,
scripts/setlocalversionacknowledges that quilt users know what they are doing. :-)
Actually, it's simply unaware of what you are doing.
Also, setlocalversion is unaware that the wireless-testing tree is tagged every day. It doesn't add the plus for the tagged revisions, even though they are very different from the version in the source Makefile.
But I'd rather not be on the mercy of a script not knowing something.
Signature · 2 lines
Regards, Pavel Roskin