On Thu, Nov 9, 2017 at 3:56 PM, Ramsay Jones
<ramsay@xxxxxxxxxxxxxxxxxxxx> wrote:
> On 09/11/17 06:46, Luc Van Oostenryck wrote:
>> --include local.mk
>> +-include .sparse.mk
>> ########################################################################
>
> I don't see any reason to make this change. The commit message
> does not make a very convincing argument! :-D
Uwe had already the same reaction. Here was the exchange:
>> Hello Luc,
>>
>> > -local.mk
>> > +.sparse.mk
>>
>> what is the motivation to hide this file? IMHO it is better to be aware
>> of eventual changes to the build system and so don't hide the file.
>>
>> Having said that I question if it is a good idea at all to provide a way
>> to change the build without dirtying the working copy.
>
> I confess that this change is just for my own comfort.
> I often need to change the CFLAGS while debugging or profiling.
> I want that to be in a file, the file must of course not be under
> version control and like .bashrc, kernel's .config or GCC's generated
> .*.o.d files, I don't need to see this file and so I prefer it's a
> hidden one.
>
> I understand your worries but since it's a file purposely changed
> so that files are compiled differently, there are no surprises.
> For dirtying the build ... yes, something could be done but really,
> personally, I don't need this, I know when I need to clean my tree.
So, yes, certainly not a strong argument.
I think I'll take a slightly different way, one that will suit me even better,
something like:
-include local.mk
+SPARSE_LOCAL_MK ?= local.mk
+include ${SPARSE_LOCAL_MK}
Would this be less objectionable?
Regards,
-- Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
