| Message ID | 1509242782-14524-1-git-send-email-f.fainelli@gmail.com |
|---|---|
| Headers | show |
| Series | Add support for specifying a custom kernel directory | expand |
Florian, All, On 2017-10-28 19:06 -0700, Florian Fainelli spake thusly: > This series allows specifying a custom kernel directory which could be an > existing git tree. This is particularly useful when doing kernel development > and having an existing git checkout where development is happening. As I replied to the patch itself: this is already covered by the opverride-srcdir mechanism, so I've marked this series as rejected in our patchwork. > Ideally, I would like to avoid doing the rsync operation involved with the "local" method > and instead just have a symbolic link from /path/to/kernel -> output/build/linux. The first rsync may take a few seconds, true, but subs=equent ones will be much faster if all you do is change a few files, especially on a hot directory, so there is not much gain to have with a local symlink. OTOH, I am currently working on out-of-tree per-pacakge build, which will (eventually) allow us to make use of the O= mechanism to build the kernel out-of-tree, and get rid of the rsync altogether. Don't hold your breath, though. ;-) Regards, Yann E. MORIN. > Comments welcome! > > Florian Fainelli (2): > pkg-generic: Don't check for trailing slashes for local method > linux: Add support for specifying a custom directory > > linux/Config.in | 10 ++++++++++ > linux/linux.mk | 3 +++ > package/linux-headers/linux-headers.mk | 5 +++++ > package/pkg-generic.mk | 2 ++ > 4 files changed, 20 insertions(+) > > -- > 2.7.4 > > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
Hi, On 10/29/2017 12:33 AM, Yann E. MORIN wrote: > Florian, All, > > On 2017-10-28 19:06 -0700, Florian Fainelli spake thusly: >> This series allows specifying a custom kernel directory which could be an >> existing git tree. This is particularly useful when doing kernel development >> and having an existing git checkout where development is happening. > > As I replied to the patch itself: this is already covered by the > opverride-srcdir mechanism, so I've marked this series as rejected in > our patchwork. > >> Ideally, I would like to avoid doing the rsync operation involved with the "local" method >> and instead just have a symbolic link from /path/to/kernel -> output/build/linux. > > The first rsync may take a few seconds, true, but subs=equent ones will > be much faster if all you do is change a few files, especially on a hot > directory, so there is not much gain to have with a local symlink. It is more about not duplicating sources unnecessarily. If you have all developers on your system do the same thing, you would end-up with a lot of copies of the same files, and if your filesystem does not already offer de-duplication, that becomes additional space used. The copy aspect is also potentially an issue since Linux kernel sources are significant enough this can become a concern over time. > > OTOH, I am currently working on out-of-tree per-pacakge build, which > will (eventually) allow us to make use of the O= mechanism to build the > kernel out-of-tree, and get rid of the rsync altogether. Don't hold your > breath, though. ;-) OK, that's good to hear. Feel free to CC when you get there and I will happily try to test that too. Thanks!