On Thu, Mar 7, 2024 at 9:10 AM Elliott Mitchell <ehem+linux@xxxxxxx> wrote: > > On Wed, Mar 06, 2024 at 12:20:17AM +0900, Masahiro Yamada wrote: > > On Tue, Mar 5, 2024 at 4:36 AM Elliott Mitchell <ehem+linux@xxxxxxx> wrote: > > > > > > On Mon, Mar 04, 2024 at 10:57:18AM +0100, Nicolas Schier wrote: > > > > > > > > can you please describe a concrete problem you want to solve with your > > > > patch set? Masahiro already asked in [1], and I still don't get your > > > > motivation while reading your cover letter. It would be helpful to see > > > > your goal when looking at your patches. > > > > > > I'm trying to develop an alternative kernel build system for one Linux > > > distribution. Due to how other pieces of the distribution work it seems > > > using the out-of-tree build mechanism to build in-tree modules may be a > > > better approach. This may be abusing the current build system, but if it > > > works without breaking anything else that should be acceptable. > > > > > > The problem I've run into is due to the mechanisms of the build system, > > > the variable $(srctree) gets the value "." while $(src) got the value of > > > $(CURDIR). > > > > > > At which point various places which use $(srctree)/$(src) ended up with > > > the value ./`pwd` and that doesn't work. Almost all uses of $(srctree) > > > had it followed with a slash, so if $(srctree) includes the trailing > > > slash, $(srctree)$(src) ends up the correct value. > > > > > > This may be outside the envelope of what is supportted, but if it works > > > without breaking anything it really should be okay. > > > I see no good reason to do this change. > > > > I will not take this series. > > Could I get you to provide further detail as to why you consider my > reasons inadaquate? > > The distribution is well-known. I believe in-tree and out-of-tree build > mechanisms being as possible to each other is a Good Thing. > > I guess I should also note, in the past (890676c65d699, 9da0763bdd825, > likely others) nicer build output has been sufficient justification for > changes. An effect of the series is a leading "./" will disappear from > many files in full build output. As such this also matches that reason. It is ideal to in-tree and out-of-tree build mechanisms look symmetrical (and perhaps could be achieved in a different way), but your approach is not the direction I want to go. -- Best Regards Masahiro Yamada
