New: make savedefconfig modifies sources

https://bugs.busybox.net/show_bug.cgi?id=8771

Bug ID: 8771
Summary: make savedefconfig modifies sources
Product: buildroot
Version: unspecified
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at buildroot.uclibc.org
Reporter: geoff at infradead.org
CC: buildroot at uclibc.org
Target Milestone: ---

When building out of the source tree 'make savedefconfig' will modify the sources in some situations. This is problematic when the sources are on read-only media. It should write to the file defconfig in the build directory.

mkdir /tmp/out
make O=/tmp/out qemu_aarch64_virt_defconfig
cd /tmp/out
make savedefconfig

In this case qemu_aarch64_virt_defconfig in the sources gets modified.

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=8771

Thomas Petazzoni <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

         Resolution|---                         |WORKSFORME
             Status|NEW                         |RESOLVED

--- Comment #1 from Thomas Petazzoni <[email protected]> --- This is the expected behavior. I personally don't like it (since it deviates from how the Linux kernel handles defconfig, and also because it's look weird), but that's the way it's supposed to work in Buildroot.

Basically, the defconfig is stored to the file pointed by BR2_DEFCONFIG. By default, this option is set to $(CONFIG_DIR)/defconfig, which would do what you want, i.e save the defconfig next to the .config file.

However, when you run "make <foobar>_defconfig", we set BR2_DEFCONFIG to "configs/<foobar>_defconfig". The original intent is to make things "transparent": if you start from a defconfig, the assumption is that you want changes made to this configuration to be saved back to the same defconfig.

You can override this at any time by changing BR2_DEFCONFIG in menuconfig/xconfig/nconfig, or simply on the command line by passing BR2_DEFCONFIG="/some/place".

As I said, I personally don't really like this behavior, and I got confused several times. The fact that the source tree is modified is indeed another drawback of this behavior. However, I didn't find this to be too problematic to really argue against the contributors who wanted this feature.

You are receiving this mail because:
You are on the CC list for the bug.

[Taking this discussion to the list]

I think we do agree that it is weird for the in-tree defconfigs. In the past,
there was no way to distinguish between the upstream in-tree defconfigs, and the defconfigs that you add to your custom buildroot tree for internal use. But now we could say that you're supposed to use BR2_EXTERNAL, So we could reset BR2_DEFCONFIG for in-tree configs.

Of course, at the moment we still point to the in-tree
configs/<boardname>_defconfig in the manual, so that would have to change first...

Regards,
Arnout

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Arnout,

To be honest, I don't see the difference between in-tree defconfigs, and defconfigs in your BR2_EXTERNAL tree. In both cases, if BR2_DEFCONFIG points to such defconfigs, when you run "make savedefconfig", you will modify version-controlled source code, which IMO isn't nice.

But again, this is really a matter of taste, and I did understand the idea of having make savedefconfig "automagically" save back to the defconfig the configuration was started from.

I simply believe that:

- It deviates from what the kernel does, which is a bit in violation of our principle "our configuration system is like the kernel"

- It modifies version-controlled source code.

I'm not sure what you mean by "we still point to". In which place of the manual?

Thomas

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Hi,

It is a tradeoff. When developing on a project using BR you want to keep the config under configuration control, and you normally want to commit minimal (savedefconfig) defconfigs, so making the steps needed to do so as few as possible is imho a very nice thing.

If on the other hand you are just trying out stuff it doesn't make much sense (but why are you running make savedefconfig in the first place then?)

True.

This can be seen both as a + and a -.

Bye, Peter Korsgaard

I use BR2_EXTERNAL and my custom stuff is in a git tree. So modifying my external config is good. I can see what changed using git difftool, revert it easily or commit an improved config.

It may deviate from a kernel savedefconfig does, but in buildroot the kernel linux-savedefconfig does exactly the same thing as buildroot savedefconfig. (if you configure the buildroot kernel for an external config.)

Personally I find the maintenance of output/.br_external as more bizarre and confusing. It does allow me to not have to remember to set BR2_EXTERNAL when make is invoked, but it gets cleaned on make clean. So using an external tree requires either a shell variable or using my unreliable wet-ware memory.

But what we have works and changing this kind of stuff breaks user habits, which cannot be easily corrected by documentation.

Regards, Steve

That _is_ a bug IMHO. output/.br_external shouldn't be removed on 'make
clean'. However, AFAICS it shouldn't be cleaned, only by distclean, and there it is appropriate of course.

Regards,
Arnout

Arnout Vandecappelle      arnout dot vandecappelle at essensium dot com
Senior Embedded Software Architect . . . . . . +32-478-010353 (mobile)
Essensium, Mind division . . . . . . . . . . . . . . http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium . . . . . BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Hi Arnout,

I just went back and tried and make clean does not clear the .br_external I guess I was just confused when trying earlier (I am still on 2015.11). Sorry about the noise, no bug.

Regards, Steve