From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeremy Rosen <jeremy.rosen@openwide.fr>
Date: Mon, 18 Mar 2013 09:10:00 +0100 (CET)
Subject: [Buildroot] [PATCH] change default location for local.mk to
 $(CONFIG_DIR)
In-Reply-To: <5146B843.9010900@mind.be>
Message-ID: <84431695.579202.1363594200099.JavaMail.root@openwide.fr>
List-Id: <buildroot.busybox.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: buildroot@busybox.net

> 
>   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