On July 8, 2014 11:20:37 AM David Faure wrote: > > > > I have a patch sitting in review for kconfig. > > What's the RR number? I can't see it in my k-f-d folder. 118489. It already has comments on it, with the decision that policy needs to be figured out before it is pushed.
> > > I'm waiting on a policy > > decision about how to handle virtuals and *NO_DEPRECATED. The policy is > > waiting on getting it written, and for that I'm working on getting a new > > contributor for helping write such documentation. > > Well, IMHO apps should be able to turn it on/off - so virtuals can't be > marked with such a macro, that would be BIC. But more below. > > > I can't really find any documentation on it. And DEFINE_NO_DEPRECATED is > > defined in *export.h, so applications can't just define it and have it > > work > > (I think? Maybe it redefining doesn't work?). And it is undefined, so if > > you have a library compiling without, warnings appear everywhere! > > No, it is defined to 0. But you're right, apps can't control it. I meant that if some libraries enable DEFINE_NO_DEPRECATED, and some do not, the compiler will complain about redefining DEFINE_NO_DEPRECATED. I can't tell if that is actually legal either. > > OK, I see two ways in which this could work: > > 1) someone wants to compile KF5 itself without deprecated stuff, to ensure > their own apps don't use any deprecated methods. That's how cmake's > GenerateExportHeader.cmake was written. And in that case, even virtual > methods could be excluded. But for this we need to provide a way to pass > DEFINE_NO_DEPRECATED to generate_export_header (like the docu suggests, with > an option). ECM could define that option for all frameworks. > > 2) someone installs a "normal" KF5 (maybe even from a distro) and wants to > ensure their app doesn't use any deprecated method. They will have to add > things like add_definitions(-DKCONFIGCORE_NO_DEPRECATED). This sounds > cumbersome, if one wants to set this for each and every framework they are > using. > > Historically in KDE we were doing something like solution 2 with > KDE_NO_DEPRECATED. At some point we had something more like solution 1 with > the "bic feature reduction and no deprecated stuff" defines in kdelibs. I > tend to think option 2 is easier to use for app developers who don't > compile their own KF5; but of course they can also just watch for > deprecation warnings. On the other hand, solution 1 is the one cmake > provides, and is more geared towards "making KF5 smaller for specific use > cases (e.g. mobile devices)", so it's potentially more useful. > > As it is right now, this doesn't seem usable to me. We need to choose one of > the two solutions and then make it work :) I agree. I figured the first step was to come up with a draft policy and post to the list for comments, and as I said I'm trying to get a new contributer to help (they have lots of experience writing documents, and have a strong technical background). Time, as always, limited our ability to get it written. I don't see option 1) being usable without fixing cmake to avoid the redefining warnings (though I imagine that is a small task). Also, I don't think any general purpose distribution would enable it, as that option would break SC and BC anytime new deprecated features are added. For single purpose devices, it's not a problem. But single purpose devices are rapidly shrinking. Option 2 definitely has its uses, but as you say deprecation warning should take care of that. Come to think of it, one problem with option 2 is that developers may enable that in their production build scripts, and thus with a new release of KF5 deprecating new behaviour, will break old applications. -- Matthew
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
