Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Jan Kiszka wrote:
>>>>> diff --git a/scripts/prepare-kernel.sh b/scripts/prepare-kernel.sh
>>>>> index 24b1f17..d8038e0 100755
>>>>> Please let me know what precisely you dislike in this approach.
>>>> You have to re-run prepare-kernel when you modify the source.
>>> Normally, you have to anyway as you add some header or some other source
>>> file during this process.
>> Not necessarily.
> 
> At worst, you run into a build error and repeat the step. Otherwise, the
> next installation will fix it silently. It's much like the missing
> DECLARE_ASSERT_SYMBOL detection and resolution, IMO even more convenient.

I do not see in what way it is more convenient. I would now have to run
prepare-kernel.sh in a case when I did not have to run it. Adding
DECLARE_ASSERT_SYMBOL to one .c file just triggers the recompilation of
the file, and relinking of the kernel.

> 
>>>> I do not like dynamic sources generation. Especially when we have a
>>>> working solution based on C pre-processor macros.
>>>>
>>> My prepare-kernel approach also detects stall debug stuff: The uitron
>>> use of XENO_DEBUG is not backed by any config option.
>> The current candidate would also detect the missing
>> DECLARE_ASSERT_SYMBOL in that case.
>>
> 
> But not
> 
> #if XENO_DEBUG(DOES_NOT_EXIST)

This can be made during the build-test and thus avoided during a normal
compilation.

I am really, strongly opposed to dynamic code generation. Especially
which greps the whole source tree, this is a waste of cpu power. Most
shell scripts are wrong when first written and do not handle errors
correctly. I already see two or three pitfalls in the script you
proposed. Globally, this is really overkill and risky.

The alternative, a 3 lines C macro, has the inconvenient of requiring
that we declare the symbol, but after all the original solution had the
same, and nobody complained. We do not add debug symbols that often.
What is important however, is that we avoid the current mess which
happened in pod.h and pod.c because they used #ifdef
CONFIG_XENO_OPT_DEBUG_NUCLEUS, and this macro solution allows to detect
such issues..

We can add the missing features of this solution in the build-test
script. This way there is 0 impact on the compilation for end-users. And
since we do run the build-test script, we are sure not to miss any
error. And if the scripts erases xenomai sources directory because of
flaky error checking, it will only erase my xenomai sources.

-- 
					    Gilles.