Why is C90 enforced in KDE?

[Kevin Kofler]

Thomas Lübking wrote:
> Compiling C99 (beyond some minor additions like the comments, but that's
> not guaranteed to be the only usage) on MSVC is a general problem to begin
> with (if you care about elder versions of what MS calls a "compiler"), so
> Boudewijn's primary problem is the usage of flex/yacc to begin with and
> he'll prefer pre-translated C-fixed-to-90 (hello sed ;-) OR flex/yacc
> being translated to *.cpp (where "i build every shit and just guess what
> the developer meant" MSVC still sucks, but not that much)

The kdewin team should just point people to a flex.exe that produces files 
that work with the bitrotten C compiler included with Visual C++. (I don't 
care whether that's an old version, a patched version, or even some other 
lex that happens to be compatible with flex, if that exists.) Then this 
solves the problem for ALL KDE software, and developers can just ship the .l 
without worrying about build tool incompatibilities.

> Otoh, developers will prefer to have flex/yacc in the CI and will require
> a cmake rule to include *.l & *.y in the source list (so it's regenerated
> on local changes) but otherwise there's (afaik) no strong reason to not
> simply ship the pre-translated sources (along the lex sources which are
> usually not invoked on build)

There is a reason: those pre-translated files are NOT sources. They are 
binaries, that happen to be in an ASCII format understood by a C compiler. 
They are really a compiler output the same way the .s file produced by g++ 
is. (I hope you aren't arguing to ship those!) So those files do not fit the 
definition of a source tarball.

Another, more practical, reason is that if a bug (maybe a security issue) 
affecting the generated output is fixed in Flex, the pre-generated files 
would not pick up the fix.

> The situation is (afaik) slightly different w/ *.moc since you might run
> into "the moc that generated this header is too old" issues (latter
> happens, so we can/should not ship pre-built mocs; but I'm not sure
> whether such problems can show up with lex as well)

There is an optional libfl.a library (by the way, if you already require the 
Flex library, you may as well require the Flex executable as well), but as 
far as I know is fairly robust when it comes to compatibility between 
versions. Still, who knows what will happen in future versions? But the 
points above are stronger arguments.

        Kevin Kofler