On 09/11/17 15:18, Luc Van Oostenryck wrote:
> 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.
Hmm, I *much* prefer that such a file is *not* 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?
Yes, thanks.
ATB,
Ramsay Jones
--
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
