At Thu, 12 Mar 2015 09:45:42 +0100, Arnd Bergmann wrote:
On Thursday 12 March 2015 07:11:48 Takashi Iwai wrote:
At Wed, 11 Mar 2015 10:46:29 +0100, Arnd Bergmann wrote:
On Wednesday 11 March 2015 07:11:18 Takashi Iwai wrote:
At Wed, 11 Mar 2015 03:22:04 +0200,
Are there any other headers like that? If this is the only one, leave it as is. The only program that reads this are some alsa-tools ones and they have already own DECLARE_BITMAP() definition. Adding the extra definition here will even break the compilation out of sudden.
I think it's a worthy goal to have the header files be compilable standalone,
In general yes, but this case is very minor issue:
- the file in question is for a hardware device-specific data definition,
- there are only two programs read this file, both can be built properly,
- and the device and the programs are very old, modifying such need extra care.
Right, we should only do it if the goal is to have all uapi headers includable standalone. For a particular header file there is very little benefit as you say, but it would be useful if we can automatically test for regressions with new or modified headers.
True. Yet another option would be just move this file back from include/uapi/sound to include/sound. Basically no user-space programs care about this file, as they have already a copy of old header fils in the package.
But maybe defining __EMU10K1_DECLARE_BITMAP() would be the easiest solution, I suppose.
thanks,
Takashi