[Buildroot] [PATCH] change default location for local.mk to $(CONFIG_DIR)

[Buildroot] [PATCH] change default location for local.mk to $(CONFIG_DIR)

[Jérémy Rosen]

the previous default of $(TOPDIR) broke the philosophy of builds with O=
which try to keep all configuration files within the $(CONFIG_DIR)
subtree
---
 Config.in |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Config.in b/Config.in
index a2c305f..c3a3e1a 100644
--- a/Config.in
+++ b/Config.in
@@ -429,7 +429,7 @@ config BR2_HAVE_DEVFILES
 
 config BR2_PACKAGE_OVERRIDE_FILE
 	string "location of a package override file"
-	default "$(TOPDIR)/local.mk"
+	default "$(CONFIG_DIR)/local.mk"
 	help
 	  A package override file is a short makefile that contains
 	  variable definitions of the form <pkg>_OVERRIDE_SRCDIR,
-- 
1.7.10.4

[Buildroot] [PATCH] change default location for local.mk to $(CONFIG_DIR)

[Thomas Petazzoni]

Dear J?r?my Rosen,

On Thu,  7 Mar 2013 11:49:23 +0100, J?r?my Rosen wrote:
> the previous default of $(TOPDIR) broke the philosophy of builds with O=
> which try to keep all configuration files within the $(CONFIG_DIR)
> subtree

Hum, that's an interesting vision of things. I think I would tend to
agree with this idea.

What do others think?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH] change default location for local.mk to $(CONFIG_DIR)

[Jeremy Rosen]

> Dear J?r?my Rosen,
> 
> On Thu,  7 Mar 2013 11:49:23 +0100, J?r?my Rosen wrote:
> > the previous default of $(TOPDIR) broke the philosophy of builds
> > with O=
> > which try to keep all configuration files within the $(CONFIG_DIR)
> > subtree
> 
> Hum, that's an interesting vision of things. I think I would tend to
> agree with this idea.
> 
> What do others think?
> 

A bit of context : 

I am trying to keep my buildroot project in git, but I am trying to 
cleanly separate "changes made to git" and "changes due to my project.

that basically means that all config file needs to be out of the 
buildroot/ subdirectory to be able to easily generate patches against
mainline and still keep my changes in git. I do that using git-subtree

I also change the location of the kernel config file for the same reason
and would do that for ctng and busybox if I needed to change them from
their default config

    Regards

    J?r?my Rosen

fight key loggers : write some perl using vim

[Buildroot] [PATCH] change default location for local.mk to $(CONFIG_DIR)

[Arnout Vandecappelle]

On 03/12/13 09:12, Jeremy Rosen wrote:
>> Dear J?r?my Rosen,
>>
>> On Thu,  7 Mar 2013 11:49:23 +0100, J?r?my Rosen wrote:
>>> the previous default of $(TOPDIR) broke the philosophy of builds
>>> with O=
>>> which try to keep all configuration files within the $(CONFIG_DIR)
>>> subtree
>>
>> Hum, that's an interesting vision of things. I think I would tend to
>> agree with this idea.
>>
>> What do others think?
>>
>
> A bit of context :
>
> I am trying to keep my buildroot project in git, but I am trying to
> cleanly separate "changes made to git" and "changes due to my project.
>
> that basically means that all config file needs to be out of the
> buildroot/ subdirectory to be able to easily generate patches against
> mainline and still keep my changes in git. I do that using git-subtree
>
> I also change the location of the kernel config file for the same reason
> and would do that for ctng and busybox if I needed to change them from
> their default config

  But $(CONFIG_DIR) is not a good location then... $(CONFIG_DIR) is 
$(TOPDIR) if doing in-tree build, and $(O) if doing out-of-tree build. 
When you delete your out-of-tree dir, local.mk will also be gone...

  I also don't really like the idea that with a defconfig, the build 
result will be different when you change the O= command line parameter.


  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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] change default location for local.mk to $(CONFIG_DIR)

[Jeremy Rosen]

> 
>   But $(CONFIG_DIR) is not a good location then... $(CONFIG_DIR) is
> $(TOPDIR) if doing in-tree build, and $(O) if doing out-of-tree
> build.
> When you delete your out-of-tree dir, local.mk will also be gone...
> 

when you build out-of-tree, you want your config to be in the O= 
directory (that's the whole point of O= as I understand it) so when 
you remove that directory you loose your .config and thus all your 
customisation. It makes sense to have local.mk there too, since 
it's also customisation. But maybe I am missing something and that's 
not the point of O= 

but in that case, what is the recommanded way of not having the .config 
in $(TOPDIR) ? is that not what I am supposed to do ? how can I save my
.config in a git repo if I have to keep it in $(TOPDIR) which is already
a buildroot repo ?

I don't want to commit my .config in the buildroot repo because if I
want to upstream my changes to $(TOPDIR) at any point, the changes to
.config will be mangled in the middle. My philosophy is that $(TOPDIR)
changes should only be potentially upstreamable stuff...


>   I also don't really like the idea that with a defconfig, the build
> result will be different when you change the O= command line
> parameter.
> 

again, I might misunderstand the point of O= but I thought that was the
very idea behind it... have multiple projects sharing their $(TOPDIR), 
maybe their dl/ subdirectory, but not their .config

there is no risk of accidentally using an incorrect O= since O= is only
used for initialisation. After that, there is a makefile in $(CONFIG_DIR)
that properly redirect you 


> 
>   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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
> 

[Buildroot] [PATCH] change default location for local.mk to $(CONFIG_DIR)

[Arnout Vandecappelle]

On 03/14/13 09:37, Jeremy Rosen wrote:
>>
>>    But $(CONFIG_DIR) is not a good location then... $(CONFIG_DIR) is
>> $(TOPDIR) if doing in-tree build, and $(O) if doing out-of-tree
>> build.
>> When you delete your out-of-tree dir, local.mk will also be gone...
>>
>
> when you build out-of-tree, you want your config to be in the O=
> directory (that's the whole point of O= as I understand it) so when
> you remove that directory you loose your .config and thus all your
> customisation. It makes sense to have local.mk there too, since
> it's also customisation. But maybe I am missing something and that's
> not the point of O=

  Indeed, it does make sense. But on the other hand, when you do a 'make 
savedefconfig', the saved config still points to that local.mk.


> but in that case, what is the recommanded way of not having the .config
> in $(TOPDIR) ? is that not what I am supposed to do ? how can I save my
> .config in a git repo if I have to keep it in $(TOPDIR) which is already
> a buildroot repo ?

  Use savedefconfig to save a defconfig and copy that to the configs/ 
directory.


> I don't want to commit my .config in the buildroot repo because if I
> want to upstream my changes to $(TOPDIR) at any point, the changes to
> .config will be mangled in the middle. My philosophy is that $(TOPDIR)
> changes should only be potentially upstreamable stuff...

  I agree with your philosophy, but at the last BR develop days it was 
decided that we will recommend only one way of working, and that is to 
put everything (including non-upstreamable changes) in the buildroot 
directory. Note that we will try not to make the  other option impossible 
(cfr. Thomas's earlier comment about a potential use of local.mk).

  What we definitely _don't_ recommend, is putting an output dir or a 
.config under version control.

  So if your use case is that you want to put local.mk under version 
control, then you should change it from its default value in every 
configuration you have, and make it point to a per-project location, e.g. 
boards/mycompany/myboard/local.mk.



  Regards,
  Arnout


>>    I also don't really like the idea that with a defconfig, the build
>> result will be different when you change the O= command line
>> parameter.
>>
>
> again, I might misunderstand the point of O= but I thought that was the
> very idea behind it... have multiple projects sharing their $(TOPDIR),
> maybe their dl/ subdirectory, but not their .config
>
> there is no risk of accidentally using an incorrect O= since O= is only
> used for initialisation. After that, there is a makefile in $(CONFIG_DIR)
> that properly redirect you

-- 
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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] change default location for local.mk to $(CONFIG_DIR)

[Jeremy Rosen]

> 
>   Indeed, it does make sense. But on the other hand, when you do a
>   'make
> savedefconfig', the saved config still points to that local.mk.
> 
> 

when building with O= the .config and the defconfig generated by make
savedefconfig are both in $(CONFIG_DIR) so I don't see why this is a 
problem


> > but in that case, what is the recommanded way of not having the
> > .config
> > in $(TOPDIR) ? is that not what I am supposed to do ? how can I
> > save my
> > .config in a git repo if I have to keep it in $(TOPDIR) which is
> > already
> > a buildroot repo ?
> 
>   Use savedefconfig to save a defconfig and copy that to the configs/
> directory.
> 


configs/ is also in $(TOPDIR) so it will bring problems when I try to
upstream 


> 
> > I don't want to commit my .config in the buildroot repo because if
> > I
> > want to upstream my changes to $(TOPDIR) at any point, the changes
> > to
> > .config will be mangled in the middle. My philosophy is that
> > $(TOPDIR)
> > changes should only be potentially upstreamable stuff...
> 
>   I agree with your philosophy, but at the last BR develop days it
>   was
> decided that we will recommend only one way of working, and that is
> to
> put everything (including non-upstreamable changes) in the buildroot
> directory. Note that we will try not to make the  other option
> impossible
> (cfr. Thomas's earlier comment about a potential use of local.mk).
> 

well, I have been experimenting with at for some time, and that's a
problematic approch... it makes it almost impossible to generate a 
patch for upstream and it makes it very hard to update your buildroot
to a newer version.

it is also very easy to forget to do a savedefconfig and to commit a 
tree with an outdated defconfig. 

so the recommanded way is to have a git branch for the project and
regularly merge upstream in the project ? 

this means that if a change is meant to be upstreamed it needs to be
done in its own git branch, submitted upstream and merged into the 
project's branch ? what if we discover we want to upstream after the 
fact ? 



>   What we definitely _don't_ recommend, is putting an output dir or a
> .config under version control.
> 

I agree for the output dir, but why the .config ? 

>   So if your use case is that you want to put local.mk under version
> control, then you should change it from its default value in every
> configuration you have, and make it point to a per-project location,
> e.g.
> boards/mycompany/myboard/local.mk.

Ideally I would like it out of $(TOPDIR) but if the recommanded way to 
do it is withing $(TOPDIR) I might do it that way... I am just not sure
how to do that in a way that allow to easily develop project-specific 
application and in a way that also allows easy upstreaming...

but i'll experiment

[Buildroot] [PATCH] change default location for local.mk to $(CONFIG_DIR)

[Thomas De Schampheleire]

Hi,

On Mon, Mar 11, 2013 at 10:26 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear J?r?my Rosen,
>
> On Thu,  7 Mar 2013 11:49:23 +0100, J?r?my Rosen wrote:
>> the previous default of $(TOPDIR) broke the philosophy of builds with O=
>> which try to keep all configuration files within the $(CONFIG_DIR)
>> subtree
>
> Hum, that's an interesting vision of things. I think I would tend to
> agree with this idea.
>
> What do others think?

I can follow the reasoning of J?r?my and have no problems with the
proposed patch.

However, unlike other config files, I still think of local.mk as a
local hack used by an individual developer, and not something you
would put under version control, neither in git nor in
project-specific patches.

Best regards,
Thomas

[Buildroot] [PATCH] change default location for local.mk to $(CONFIG_DIR)

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Tue, 12 Mar 2013 09:26:51 +0100, Thomas De Schampheleire wrote:

> However, unlike other config files, I still think of local.mk as a
> local hack used by an individual developer, and not something you
> would put under version control, neither in git nor in
> project-specific patches.

I would say it depends. We may imagine that some people use git
submodules to achieve something like this:

 + project
 --+ buildroot
 --+ linux
 --+ uboot
 --+ application

with a suitable local.mk, under version control, that tells Buildroot
to look for the kernel source code in $(TOPDIR)/../linux, U-Boot
source code in $(TOPDIR)/../uboot, etc.

(in the above, buildroot, linux, uboot and application are separate Git
repositories that are put together into a global project Git
repositories using git submodules).

But J?r?my's patch doesn't prevent from doing that, since it just
changes the default value.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com