Why is C90 enforced in KDE?
Kevin Kofler
kevin.kofler at chello.at
Sun Dec 20 03:21:29 GMT 2015
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
More information about the kde-core-devel
mailing list