Added a small usability improve for Unix.mk savedefconfig

[ValentiWorkLearning]

Note: Please adhere to Contributing Guidelines.

Summary

I've found that while working on the custom board initial platform bringup it's a kind of:

• make menuconfig
• make savedefconfig
• git add
• git commit

When the board is configured to be out-of-tree, then it's possible to simply forget where the defconfig is stored/how to navigate into it.

Impact

Buildsystem

Testing

Just a simple make savedefconfig is enough:

"The defconfig was generated successfully at /workspaces/rtos_labs/nuttxspace/nuttx/defconfig .If you're building out-of-tree configuration, then copy it to your configuration defconfig"

[simbit18]

hi @ValentiWorkLearning replace Unix.ml with Unix.mk in the title

[anchao]

Let's implement autosave directly, aligning with cmake's behavior

https://github.com/apache/nuttx/blob/master/cmake/menuconfig.cmake#L98-L99

[ValentiWorkLearning]

@anchao hm.. That's good idea. It seems that this flow has to be same for other tools(buildroot for instance). So, technically make savedefconfig should directly write to the original defconfig file. Would this be the expected behaviour?

[anchao]

There is no standard that specifies the behavior of savedefconfig. I think the change is worth if the improvement could make developers more efficient,

[acassis]

@anchao what is the goal of this cmake autosave? If I understood correctly when user run "make savedefconfig" it will replace the original defconfig for current board profile. Although this behavior seems good at first glance, the reason because Greg didn't implement this way it because normally the developer will use a base board:nsh profile to modify and create a local defconfig that he/she will move to a new configs/namedir that will be created. I think the cmake autosave should require a flag to force this behavior, something like "make -f savedefconfig". Maybe @patacongo could give more details here.

[anchao]

@anchao what is the goal of this cmake autosave? If I understood correctly when user run "make savedefconfig" it will replace the original defconfig for current board profile. Although this behavior seems good at first glance, the reason because Greg didn't implement this way it because normally the developer will use a base board:nsh profile to modify and create a local defconfig that he/she will move to a new configs/namedir that will be created. I think the cmake autosave should require a flag to force this behavior, something like "make -f savedefconfig". Maybe @patacongo could give more details here.

My view is straightforward: change it in a way that is most convenient for developers.
Not replacing the original defconfig with savedefconfig was reasonable before the emergence of git, developers did not have diff tools to check for differences between their work and original config
After git, if the original configuration is directly replaced by savedefconfig, developers can easily use git diff to check whether the changes as expectations. If not, they only need to use git checkout to restore the file.
I think for 90% of individual developers, this approach will enhance their efficiency.

Furthermore, this improvement could also shorten the CI-CD time, and the process of refresh.sh could be optimized.

refresh.sh (6s)

archer@archer:~/code/nuttx/n6/nuttx$ time ./tools/refresh.sh --silent sim/nsh
  [1/1] Normalize sim/nsh

real	0m6.049s
user	0m3.137s
sys	0m1.988s

autosave (1.5s)

archer@archer:~/code/nuttx/n6/nuttx$ time make savedefconfig
Loaded configuration '.config'
Minimal configuration saved to 'defconfig.tmp'

real	0m1.363s
user	0m0.802s
sys	0m0.422s

[acassis]

@anchao your point makes sense, but then it should be important to have an option to not replace the original defconfig, because it will add a more steps for developers creating new profiles: currently after the "cmake savedefconfig" they will need:
cp boards/xxx/xxx/xxxx/configs/nsh/defconfig /backup/configs/
git checkout boards/xxx/xxx/xxxx/configs/nsh/defconfig
mkdir boards/xxx/xxx/xxxx/configs/newbrdcfg/
cp /backup/configs/defconfig boards/xxx/xxx/xxxx/configs/newbrdcfg/

Compared with current way using "make savedefconfig":
mkdir boards/xxx/xxx/xxxx/configs/newbrdcfg/
cp defconfig boards/xxx/xxx/xxxx/configs/newbrdcfg/

[anchao]

@acassis please think about when users would want to do the savedefconfig. Could it be to save a copy? I don't think so, What they actually want is to replace the original version.

[anchao]

@anchao your point makes sense, but then it should be important to have an option to not replace the original defconfig, because it will add a more steps for developers creating new profiles: currently after the "cmake savedefconfig" they will need: cp boards/xxx/xxx/xxxx/configs/nsh/defconfig /backup/configs/ git checkout boards/xxx/xxx/xxxx/configs/nsh/defconfig mkdir boards/xxx/xxx/xxxx/configs/newbrdcfg/ cp /backup/configs/defconfig boards/xxx/xxx/xxxx/configs/newbrdcfg/

Compared with current way using "make savedefconfig": mkdir boards/xxx/xxx/xxxx/configs/newbrdcfg/ cp defconfig boards/xxx/xxx/xxxx/configs/newbrdcfg/

Regarding first case, why not back up the old version first?

[acassis]

@acassis please think about when users would want to do the savedefconfig. Could it be to save a copy? I don't think so, What they actually want is to replace the original version.

@anchao I think we are talking about different things. Normally users create a new config using an old one as base. But of course, it is possible to change the way the do it, now instead of using boardname:nsh as start point the need first to copy the "nsh" board profile to a new place (i.e. "newbrdcfg") and the run boardname:newbrdcfg

I think this approach is ok, we just need to change the way normally people do it (as I described previously)

[ValentiWorkLearning]

Re-requested review just to ask, what should be done with this PR then 😄
Should I refactor it somehow or can we merge it?

[xiaoxiang781216]

Re-requested review just to ask, what should be done with this PR then 😄 Should I refactor it somehow or can we merge it?

@anchao do you have more concern?