Why is C90 enforced in KDE?
Hi, Kipi-plugins fails to build with flex 2.6. This is due to the autogenerated code in libpanorama containing //-style comments, which are disallowed in C90. Adding -std=c99 to the CFLAGS at compile time doesn't have any effect, since it is overriden by kdelibs (and by extra-cmake-modules in KF5). What is the reason for this? And is there any way to force using C99?
Re: Why is C90 enforced in KDE?
On Sonntag, 6. Dezember 2015 16:08:04 CEST, Antonio Rojas wrote: C90. Adding -std=c99 to the CFLAGS at compile time doesn't have any effect, since it is overriden by kdelibs (and by extra-cmake-modules in KF5). What is the reason for this? I guess because of poor compiler support. One needs MSVC 2013 for at least *some* C99 support :-P (2015 should be somewhat complete, though) Cheers, Thomas
Re: Why is C90 enforced in KDE?
On Sunday, December 06, 2015 04:08:04 PM Antonio Rojas wrote: > Hi, > Kipi-plugins fails to build with flex 2.6. This is due to the autogenerated > code in libpanorama containing //-style comments, which are disallowed in > C90. Adding -std=c99 to the CFLAGS at compile time doesn't have any effect, > since it is overriden by kdelibs (and by extra-cmake-modules in KF5). What > is the reason for this? And is there any way to force using C99? > We have (had?) a policy that flex/yacc generated source files should be part of the repo. do not make everyone run flex/yacc when building.
Re: Why is C90 enforced in KDE?
2015-12-06 13:13 GMT-03:00 Allen Winter : > We have (had?) a policy that flex/yacc generated source files should be part > of the repo. > do not make everyone run flex/yacc when building. I disagree with this. It has happened to me more than once that I modify a flex file, regenerate it, and find it has been broken for *years* due to incompatibilities with newer flex versions and nobody noticed. Or I forget to regenerate it. Should we put .mo files in the SVN translation directories so that people don't need msgfmt? Should we put .moc files in git? kdevelop-pg-qt generated parsers? Code made from .ui files? Code made by kconfig_compiler from .kcfg files? kapptemplate tarballs? If it was up to me, there wouldn't even be .png icons in git version control, they would be generated from their .svg files at compile time. -- Nicolás
Re: Why is C90 enforced in KDE?
2015-12-06 12:54 GMT-03:00 Thomas Lübking : > On Sonntag, 6. Dezember 2015 16:08:04 CEST, Antonio Rojas wrote: >> >> C90. Adding -std=c99 to the CFLAGS at compile time doesn't have any >> effect, since it is overriden by kdelibs (and by extra-cmake-modules in >> KF5). What is the reason for this? > > > I guess because of poor compiler support. > One needs MSVC 2013 for at least *some* C99 support :-P > (2015 should be somewhat complete, though) I guess -std=c90 is used to make sure nobody accidentally introduces C99 features that will break in older compilers. However, all compilers we care about support // comments in C code... I didn't find any way for gcc to allow // but disallow other C99 features. Maybe we should use -std=gnuc90 -Wpedantic in gcc instead of -std=c90, so that GNU extensions (including // comments) are allowed but give warnings. Then we ignore warnings about // comments and pay attention to others (in case someone accidentally introduces a GNU extension and breaks the build in other compilers). Of course, another way to get what we want is to not use -std=c90, but have proper CI for MSVC. That way we'll know if someone adds unsupported C99 features :) -- Nicolás
Re: Why is C90 enforced in KDE?
On Sunday, December 06, 2015 01:34:51 PM Nicolás Alvarez wrote: > 2015-12-06 13:13 GMT-03:00 Allen Winter : > > We have (had?) a policy that flex/yacc generated source files should be > > part of the repo. > > do not make everyone run flex/yacc when building. > > I disagree with this. It has happened to me more than once that I > modify a flex file, regenerate it, and find it has been broken for > *years* due to incompatibilities with newer flex versions and nobody > noticed. Or I forget to regenerate it. > > Should we put .mo files in the SVN translation directories so that > people don't need msgfmt? Should we put .moc files in git? > kdevelop-pg-qt generated parsers? Code made from .ui files? Code made > by kconfig_compiler from .kcfg files? kapptemplate tarballs? > > If it was up to me, there wouldn't even be .png icons in git version > control, they would be generated from their .svg files at compile > time. > I said the policy is flex/yacc generated. not all generated. perhaps flex is more consistently available on all platforms these days. last I recall flex on Windows proved difficult to deal with, but maybe things are better these days.
Re: Why is C90 enforced in KDE?
On Sunday 06 December 2015 13:34:51 Nicolás Alvarez wrote: > If it was up to me, there wouldn't even be .png icons in git version > control, they would be generated from their .svg files at compile > time. You do not seem to be aware of the fact that (AFAIK) the PNGs were hand- optimized by Nuno and others. I'm pretty sure that Nuno would personally hunt down each and everyone of us ignorant non-designers if we replaced the PNGs with auto-generated ones. :-) Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Why is C90 enforced in KDE?
On Sonntag, 6. Dezember 2015 17:41:07 CEST, Nicolás Alvarez wrote: Then we ignore warnings about // comments and pay attention to others Wtf does flex/yacc produce incompliant comments? Seriously, COMMENTS! That's a convenience thing. int foo = bar; // bar defined in wherever is simpler than int foo = bar; /* bar defined in wherever */ but a code generator isn't lazy. There must be a way to avoid that? Otherwise one might convince them to create cpp/cxx suffixes so that compilers will invoke the C++ compiler? Cheers, Thomas
Re: Why is C90 enforced in KDE?
2015-12-06 18:59 GMT-03:00 Thomas Lübking : > On Sonntag, 6. Dezember 2015 17:41:07 CEST, Nicolás Alvarez wrote: >> >> Then we ignore warnings about // comments and pay attention >> to others > > > Wtf does flex/yacc produce incompliant comments? > Seriously, COMMENTS! > That's a convenience thing. > > int foo = bar; // bar defined in wherever > > is simpler than > > int foo = bar; /* bar defined in wherever */ > > but a code generator isn't lazy. > There must be a way to avoid that? > > Otherwise one might convince them to create cpp/cxx suffixes so that > compilers will invoke the C++ compiler? I have never used yacc, but I know you can make flex produce a file named .cpp and even use C++ code inside your actions. There is even an (experimental, unstable) flex option to make it output an actual C++ parser class. -- Nicolás
Re: Why is C90 enforced in KDE?
Thomas Lübking wrote: > Wtf does flex/yacc produce incompliant comments? > Seriously, COMMENTS! > That's a convenience thing. I remember a mail from several years ago where Flex developers said they had no interest in supporting an ancient C standard when C99 has been out for years. (I think it was about using stdint.h or something like that.) So I am not surprised that they are now using C99 comments (which ARE compliant to the current C standard, and have been for 16 years (!)). Kevin Kofler
Re: Why is C90 enforced in KDE?
Nicolás Alvarez wrote: > I disagree with this. It has happened to me more than once that I > modify a flex file, regenerate it, and find it has been broken for > *years* due to incompatibilities with newer flex versions and nobody > noticed. Or I forget to regenerate it. > > Should we put .mo files in the SVN translation directories so that > people don't need msgfmt? Should we put .moc files in git? > kdevelop-pg-qt generated parsers? Code made from .ui files? Code made > by kconfig_compiler from .kcfg files? kapptemplate tarballs? +1, of course we should not. Generated files have no business being in a source control or in source tarballs. "BuildRequires: flex" is one line in a distro specfile. Kevin Kofler
Re: Why is C90 enforced in KDE?
On Montag, 7. Dezember 2015 03:14:05 CEST, Kevin Kofler wrote: not surprised that they are now using C99 comments (which ARE compliant to the current C standard, and have been for 16 years (!)). Sure, but since it seems it's the only C99 feature used(?, stdint is more a library thing, at least gcc more or less tagged it as such¹), this looks like an intended break. At least I completely fail to see the advantage of c++ style comments for a machine (rather the opposite, since "dumb" appending to lines can now produce undesired results) Either way, Qt5 supports down to MSVC 2010, Qt4 down to MSVC 2008, so either we - raise the bar in kdelibs/KF5 to require a C99 compliant compiler (as a build dep requires it, "we just need //" isn't true - the requirements are controlled outside - ship only pre-produced and hand-fixed code from flex/yacc - pipe flex/yacc results through c++ rather than the C compiler Cheers, Thomas [1] https://gcc.gnu.org/c99status.html
Re: Why is C90 enforced in KDE?
On Mon, 7 Dec 2015, Kevin Kofler wrote: +1, of course we should not. Generated files have no business being in a source control or in source tarballs. "BuildRequires: flex" is one line in a distro specfile. Unfortunately, Linux distros aren't the main platform anymore for the KDE software _I_ maintain. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Why is C90 enforced in KDE?
Il Mon, 07 Dec 2015 13:17:53 +0100, Boudewijn Rempt ha scritto: > Unfortunately, Linux distros aren't the main platform anymore for the > KDE software _I_ maintain. Given you've said this multiple times, with my packager hat on I'll just mention this: just don't make it harder *for us* to work just because you're targeting another platform. You may not care for Linux distros, but there are people who *do*. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: A29D259B
Re: Why is C90 enforced in KDE?
On Montag, 7. Dezember 2015 15:54:40 CEST, Luca Beltrame wrote: Given you've said this multiple times, with my packager hat on I'll just mention this: just don't make it harder *for us* to work just because you're targeting another platform. I actually don't think this related at all. 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) Distros and notably self-builders would probably prefer such as well (less build time dependency, yeah!), so there's no conflict. 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) 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) Cheers, Thomas, Baseball cap - I've not hats.
Re: Why is C90 enforced in KDE?
On Monday, December 07, 2015 04:33:37 PM Thomas Lübking wrote: > On Montag, 7. Dezember 2015 15:54:40 CEST, Luca Beltrame wrote: > > Given you've said this multiple times, with my packager hat on I'll just > > mention this: just don't make it harder *for us* to work just because > > you're targeting another platform. > > I actually don't think this related at all. > > 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) > > Distros and notably self-builders would probably prefer such as well (less > build time dependency, yeah!), so there's no conflict. > > 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) > > 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) As long as you also ship the source, as a Debian packager, I'm happy. We have to have preferred form of modification and the ability to rebuild from that source. It's not 100% required that we rebuild, but how do you know you can, unless you do. I don't mind the additional dependency at all. My preference would be that on Linux, at least, if flex/yacc are detected, the rebuilding is automatic. Scott K
Re: Why is C90 enforced in KDE?
On Mon, 7 Dec 2015, Luca Beltrame wrote: Il Mon, 07 Dec 2015 13:17:53 +0100, Boudewijn Rempt ha scritto: Unfortunately, Linux distros aren't the main platform anymore for the KDE software _I_ maintain. Given you've said this multiple times, Yes, and I'll go on saying it until I feel people are listening... Which I feel hasn't happened yet. with my packager hat on I'll just mention this: just don't make it harder *for us* to work just because you're targeting another platform. There are two sides, of course: if making it easier for a distribution to package KDE software makes it harder for an application to be packaged for another distribution, where do we go? What's most important? Just adding a dependency because all linux distributions have it so it's no sweat can cause huge problems. You may not care for Linux distros, but there are people who *do*. I care about Linux, I care for Linux distributions and I've always done. I hate having to work on OSX (especially OSX) or Windows, but I don't have a choice here. And if the KDE frameworks are supposed to be cross-platform, development needs to reflect that, and anything that's making life easy for a distribution should be weighed and considered and maybe rejected if it's making life harder for users of the KDE frameworks on other platforms. The alternative is doing what Gnome did: declare the KDE Frameworks Linux-only. That would be a clear, honest step to take, and I wouldn't actually oppose it. But it would put an end to the story that KDE Frameworks are just additions to Qt that everyone can use. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Why is C90 enforced in KDE?
On Montag, 7. Dezember 2015 17:22:47 CEST, Boudewijn Rempt wrote: There are two sides, of course: if making it easier for a distribution to package KDE software makes it harder for an application to be packaged for another distribution, where do we go? What's most important? Just adding a dependency because all linux distributions have it so it's no sweat can cause huge problems. Back on topic: do you actually have trouble with invoking flex/yacc* to generate code or do you have a problem with the generated (C99) code (what seems to be a pretty new problem - and is on Linux/any distro because KF5 does --std=c90)? Or was this just a general "Hey, there's a world beyond Linux" remark? You also may have some (personal, at least) data on relevant MSVC 2013 is in practice? Because every gcc in the wild as well as clang should be able to handle C99 - and so should MSVC 2015 and the intel compiler(s of the past). Afaics, MSVC 2013 is the deal breaker here; but no warranty on that statement... Cheers, Thomas * other than "install it" - Windows doesn't come with a compiler by default either.
Re: Why is C90 enforced in KDE?
Am 07.12.2015 um 21:36 schrieb Thomas Lübking: > On Montag, 7. Dezember 2015 17:22:47 CEST, Boudewijn Rempt wrote: > >> There are two sides, of course: if making it easier for a distribution >> to package KDE software makes it harder for an application to be packaged >> for another distribution, where do we go? What's most important? Just >> adding a dependency because all linux distributions have it so it's no >> sweat can cause huge problems. > > Back on topic: do you actually have trouble with invoking flex/yacc* to > generate code or do you have a problem with the generated (C99) code > (what seems to be a pretty new problem - and is on Linux/any distro > because KF5 does --std=c90)? > > Or was this just a general "Hey, there's a world beyond Linux" remark? > > You also may have some (personal, at least) data on relevant MSVC 2013 > is in practice? > Because every gcc in the wild as well as clang should be able to handle > C99 - and so should MSVC 2015 and the intel compiler(s of the past). > Afaics, MSVC 2013 is the deal breaker here; but no warranty on that > statement... IIRC the problem here is(was) the version of flex/bison used. There was only a very outdated version of flex/bison available for a long time, and this one produced different results from a more modern version. When I looked last, there was a newer build available for both, which was recent enough and which also produced valid results (in at least some cases). I would recommend thus to test those two first, to see if there is a problem at that point at all (and if needed, then it is possible to decide that on a case by case basis - there shouldn't be to many flex/bison uses in total KDE code). About C99: I am not sure which compiler is currently required with MSVC, but if it is 2013 or below, then only some C99 features are supported. I tried to create a C99-to-C90 compiler with the help of clang, but this failed pretty early. So my advice would be to not make C90 default, but to allow some C99 features, but with improved CI instead. regards, Patrick
Re: Why is C90 enforced in KDE?
On Monday 07 December 2015 09:29:59 Thomas Lübking wrote: > Either way, Qt5 supports down to MSVC 2010, Qt4 down to MSVC 2008, so either > we Qt 5.6 supports MSVC 2008. Qt 5.7 raises the minimum to MSVC 2012. Neither compiler supports stdint.h or some other nice C99 functions, like isnanf. You need MSVC 2013 for that. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Why is C90 enforced in KDE?
On Monday 07 December 2015 21:36:13 Thomas Lübking wrote: > You also may have some (personal, at least) data on relevant MSVC 2013 is in > practice? Because every gcc in the wild as well as clang should be able to > handle C99 - and so should MSVC 2015 and the intel compiler(s of the past). > Afaics, MSVC 2013 is the deal breaker here; but no warranty on that > statement... MSVC 2013 has good support for C99. MSVC 2012 does not. I should point all that MSVC has supported // comments in C sources since before it was known as Visual. But that's not the problem. The problem is the C99 Library, which MSVC did not support until 2013 and it only did so because C++11 imported it by reference. Microsoft does not care for C. They didn't implement C99 because they didn't want to, not because their compiler team was unable to. So my recommendation: write C++ code. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Why is C90 enforced in KDE?
On Sun, December 6, 2015 16:08:04 Antonio Rojas wrote: > Hi, > Kipi-plugins fails to build with flex 2.6. This is due to the autogenerated > code in libpanorama containing //-style comments, which are disallowed in > C90. Adding -std=c99 to the CFLAGS at compile time doesn't have any effect, > since it is overriden by kdelibs (and by extra-cmake-modules in KF5). What > is the reason for this? And is there any way to force using C99? I'm not sure offhand... it may be due to trying to support builds using MSVC on Windows (which has poor C99 or later support). On the other hand even MSVC supports //comments in C code. I think there's some way to get CMake to add compiler flags for .c files in particular; another option is to have flex generate a .cpp file, assuming that the code being generated is safely in the common subset of C and C++. Regards, - Michael Pyne
Re: Why is C90 enforced in KDE?
On Mon, 7 Dec 2015, Thomas Lübking wrote: On Montag, 7. Dezember 2015 17:22:47 CEST, Boudewijn Rempt wrote: There are two sides, of course: if making it easier for a distribution to package KDE software makes it harder for an application to be packaged for another distribution, where do we go? What's most important? Just adding a dependency because all linux distributions have it so it's no sweat can cause huge problems. Back on topic: do you actually have trouble with invoking flex/yacc* to generate code or do you have a problem with the generated (C99) code (what seems to be a pretty new problem - and is on Linux/any distro because KF5 does --std=c90)? Or was this just a general "Hey, there's a world beyond Linux" remark? It was a more general remark to Kevin: he might have it easy because he can add just a line to a spec file and be happy, but in the big, bad world, every dependency is a burden. You also may have some (personal, at least) data on relevant MSVC 2013 is in practice? Because every gcc in the wild as well as clang should be able to handle C99 - and so should MSVC 2015 and the intel compiler(s of the past). Afaics, MSVC 2013 is the deal breaker here; but no warranty on that statement... I'm right now using msvc 2015 myself -- which gives other problems with other dependencies. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Why is C90 enforced in KDE?
On 10 December 2015 at 12:04, Boudewijn Rempt wrote: > I'm right now using msvc 2015 myself -- which gives other problems with > other > dependencies. Microsoft now has clang (running on the Microsoft Code Generator as well as LLVM) - maybe we could look into using that on Windows? It's supposed to be an (optional, IIRC) part of VS2015 and will be continually supported and updated. So if we can kick out cl.exe support, that's one less compiler frontend to support. Note that clang with Microsoft CodeGen is theoretically pretty much the same as cl.exe (in both cases the AST is converted to machine code by MSCG only), except that with clang we get superior parser and C++11/14 and C90 support. -- Boudhayan
Re: Why is C90 enforced in KDE?
On Thu, 10 Dec 2015, Boudhayan Gupta wrote: On 10 December 2015 at 12:04, Boudewijn Rempt wrote: I'm right now using msvc 2015 myself -- which gives other problems with other dependencies. Microsoft now has clang (running on the Microsoft Code Generator as well as LLVM) - maybe we could look into using that on Windows? It's supposed to be an (optional, IIRC) part of VS2015 and will be continually supported and updated. So if we can kick out cl.exe support, that's one less compiler frontend to support. Note that clang with Microsoft CodeGen is theoretically pretty much the same as cl.exe (in both cases the AST is converted to machine code by MSCG only), except that with clang we get superior parser and C++11/14 and C90 support. Well, it's more like "building boost with msvc 2015 doesn't add the compiler version number to the dll names, which means that the cmake code that looks for boost fails to find the dll's, even though they are there, because the name pattern cmake is hard-coded for fails, so you need to manually rename the dll's" or "msvc 2015 still insists on really small stacks, so g'mic's stack based recursive parser, which needs 8mb of stack minimum, runs out of stack". It's all those effing little things that add up and make building an application with a few dozen dependencies a herculean task. And every dependency seems to have _something_. In the Qt4 days, Qt didn't want to link to zlib.lib, it needed libzlib.lib, for instance. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Why is C90 enforced in KDE?
Thomas Lübking wrote: > as a build dep requires it, "we just need //" isn't true - the > requirements are controlled outside Well, in that case, this: > - pipe flex/yacc results through c++ rather than the C compiler won't do much good, because the C++ compiler will not necessarily grok any other C99isms in the code. This only really helps for "//" comments. My suggestion is: * do not ship Flex-generated code, and * document the compatibility issue, and let it be the user's responsibility to use a version of Flex compatible with their compiler, which may be an older or patched one. This is entirely a compatibility issue between 2 build tools (Flex and the compiler), I don't see how this should be our (KDE's) problem. Kevin Kofler
Re: Why is C90 enforced in KDE?
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
Re: Why is C90 enforced in KDE?
On Sonntag, 20. Dezember 2015 04:08:20 CEST, Kevin Kofler wrote: - pipe flex/yacc results through c++ rather than the C compiler won't do much good, because the C++ compiler will not necessarily grok any other C99isms in the code. This only really helps for "//" comments. Afaiu flex/yacc can produce c++ code, but apparently that only holds for flex/bison (yacc apparently cannot deal with c++ output from flex...) Bison however seems available in the gnuwin32 package, so that should be no problem preventing a c++ chain on flex/yacc Cheers, Thomas
Re: Why is C90 enforced in KDE?
On Sonntag, 20. Dezember 2015 04:21:29 CEST, Kevin Kofler wrote: 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++. So we only need somebody who forks the hardly maintained flex/yacc tools for windows... It should be simpler to point windows users to a recent MSVC (2015), gcc, clang, or icc (ie. mandate them for KF5, raising the bar from Qt5) We could then indeed raise to -c99 and "guarantee" compilation only for compatible compilers (while older MSVC *may* still work) I'd say it's up to the kdewin people to state their preferences here - require bison and switch to c++ in the flex/yacc toolchain - (soft)require a c99 compliant compiler (where MSVC 2013 *may* still work) 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. Actually, that rather supports shipping pre-generated code (given the apparent support situation of flex/yacc on windows - windows users could encounter flex bugs none of us ever sees and the backtraces make no sense...) Cheers, Thomas
Re: Why is C90 enforced in KDE?
Am 20.12.2015 um 10:24 schrieb Thomas Lübking: On Sonntag, 20. Dezember 2015 04:21:29 CEST, Kevin Kofler wrote: 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++. So we only need somebody who forks the hardly maintained flex/yacc tools for windows... I think this one is actively maintained: https://sourceforge.net/projects/winflexbison/ and I used it to compile Qt5.5 with msvc2013 (somewhere in the qt docs there's a link to this project). So it *should* work with KF5 too. But someone has to test it. It's out of my scope because currently I don't have a working environment for KF5. Christian
Generated files in version control (was: Re: Why is C90 enforced in KDE?)
2015-12-06 17:28 GMT-03:00 Ingo Klöcker : > On Sunday 06 December 2015 13:34:51 Nicolás Alvarez wrote: >> If it was up to me, there wouldn't even be .png icons in git version >> control, they would be generated from their .svg files at compile >> time. > > You do not seem to be aware of the fact that (AFAIK) the PNGs were hand- > optimized by Nuno and others. I'm pretty sure that Nuno would personally > hunt down each and everyone of us ignorant non-designers if we replaced > the PNGs with auto-generated ones. :-) I am aware that Nuno manually chose rendering engine and scaling method for every individual Oxygen icon based on seeing which one gave (subjectively) better results. That is not documented anywhere, and we can't modify an icon and re-render it with the same quality unless we ship Nuno's brain along with oxygen-icons.tar.bz2 (I don't think there is any working implementation of RFC1437), because we don't know what rendering engine, scaling method, and bitmap modifications were used. If I want to make an Oxygen-style icon for my application's document format, I can copy the .svg for an existing file format icon, put my application logo, leave the paper, and... who knows how to produce the magic .png from that. No documentation, no script. I could even bring licensing into the discussion. What is the "preferred form for modification" (in the GPL sense) of oxygen icons? What is the Corresponding Source (in the GPL sense) of the .png files? -- Nicolás
Re: Generated files in version control (was: Re: Why is C90 enforced in KDE?)
On Sonntag, 6. Dezember 2015 22:23:01 CEST, Nicolás Alvarez wrote: I am aware that Nuno manually chose rendering engine and scaling method for every individual Oxygen icon based on seeing which one gave (subjectively) better results. That is not documented anywhere Seriously? I mean, are you saying the choices where not recorded anywhere? (To automize re-generation on a rule base) I don't think there is any working implementation of RFC1437 Rumor has it that Dr. Ira Graves will have made some progress on this particular issue. If I want to make an Oxygen-style icon of vastly inferior quality ... :-P for my application's document format, I can copy the .svg for an existing file format icon, put my application logo, leave the paper, and... who knows how to produce the magic .png from that. No documentation, no script. Is this a real world issue or is the solution being "breeze"? I could even bring licensing into the discussion. Afaiu you can't - png is the "source", because they were post-processed in addition?!? Even if not: it doesn't matter whether you use inkscape or gimp or krita or illustrator or photoshop or MS paint to create a raster image (or whether you provide intermediate results as well) - otherwise things would get *really* complex, because the *entire* production process of the image would have to be documented to eg. allow recretation of a png drawn in gimp (Mask here, gradient there. Gaussian blur, 40% overlay. Flatten, displacement noise, yaddayaddayadda...) IOW, iamges don't fit code licenses at all. Cheers, Thomas
Re: Generated files in version control (was: Re: Why is C90 enforced in KDE?)
2015-12-06 18:46 GMT-03:00 Thomas Lübking : > On Sonntag, 6. Dezember 2015 22:23:01 CEST, Nicolás Alvarez wrote: > >> I am aware that Nuno manually chose rendering engine and scaling >> method for every individual Oxygen icon based on seeing which one gave >> (subjectively) better results. That is not documented anywhere > > Seriously? I mean, are you saying the choices where not recorded anywhere? > (To automize re-generation on a rule base) As far as I know they weren't. I will be grateful if you can find the record of those choices, so far I couldn't :) >> If I want to make an Oxygen-style icon > > of vastly inferior quality ... :-P It will look better to stick my app logo into the real-artist-designed piece-of-paper-with-shadow than to draw an icon from scratch... >> I could even bring licensing into the discussion. > > > Afaiu you can't - png is the "source", because they were post-processed in > addition?!? Both Oxygen and Breeze icons are under the LGPL, so I *can* bring licensing into discussion. If you think png is the real source, that's a possible answer to my question, it doesn't mean my question is N/A :) If the Preferred Form of Modification is the PNGs, it means the best way to modify an existing icon is to modify the PNG, so we shouldn't need the SVG around at all. I don't think that's the case. Surely the preferred way to modify an icon is to edit the SVG and rasterize it again. In that case part of the Corresponding Source is missing: how it was rasterized. > Even if not: it doesn't matter whether you use inkscape or gimp or krita or > illustrator or photoshop or MS paint to create a raster image (or whether > you provide intermediate results as well) - otherwise things would get > *really* complex, because the *entire* production process of the image would > have to be documented to eg. allow recretation of a png drawn in gimp (Mask > here, gradient there. Gaussian blur, 40% overlay. Flatten, displacement > noise, yaddayaddayadda...) If you used gimp, you should put your multilayer .xcf in version control, although in that case I may concede that re-rendering it at build time is a pain, and a .png should be committed too. But at least it's easy to reproduce the exact same bitmap if needed. -- Nicolás
Re: Generated files in version control (was: Re: Why is C90 enforced in KDE?)
On Montag, 7. Dezember 2015 01:08:31 CEST, Nicolás Alvarez wrote: It will look better to stick my app logo into the real-artist-designed piece-of-paper-with-shadow than to draw an icon from scratch... Afaiu, one should have asked the oxygen team to avoid this kind of patched icons. I don't think that's the case. Surely the preferred way to modify an icon is to edit the SVG and rasterize it again. Again: that's processing. The required file was the png (since svg icons were initially not even supported and even now the Qt svg renderer is completely not up to inkscape features extending vanilla svg) If you used gimp, you should put your multilayer .xcf **mt** - it's not simply "multilayer", that's just an intermediate result. The (hypothetical) icon was forged using several destructive processes to get the pixels colorful in the desired way - which are not documented anywhere. It could even haven been done in the very same layer or layer merging was one of the required process steps. A rastered image really completely rests in itself - no matter what tools were used to forge it. A vector editor is just a process detail; the same result could have been achieved in MS paint (with a lot of time ;-) Cheers, Thomas