| Message ID | 1362653363-24915-1-git-send-email-jeremy.rosen@openwide.fr |
|---|---|
| State | Accepted |
| Commit | eda3d0e1d01c3f3e32a24759ddd107574a118c8c |
| Headers | show |
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
> 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
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
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
> > 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 >
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
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
> > 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
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,