Il giorno 31/ott/2011, alle ore 13:17, <[email protected]> <[email protected]> ha scritto:
> On 10/31/11 10:53 AM, "ext Thiago Macieira" <[email protected]> wrote: > >> On Monday, 31 de October de 2011 10:44:16 Giovanni Bajo wrote: >>> What is the policy on adding new dependencies to the Qt project? >> >> I'd guess that the maintainer for that module approves. For qtbase.git, >> that's >> Lars. >> >> Importing third-party source code requires approval under the CLA too. >> >>> To me, it seems a bad idea to add a dependency on any library unless >>> there >>> is a specific use case were it is really necessary. So adding Boost just >>> because it's "cool" (for some definition is cool) doesn't look like a >>> deal. >>> It doesn't help that I specifically dislike Boost, but that's not the >>> subject of this comment. >> >> Agreed. But I know João wouldn't do that: his complaint was that we >> reinvent >> the wheel just so we don't add the dependency. So I agree with him that >> if >> there is an implemented solution with no ill side effects, there's no >> reason >> not to use it. > > Compile/build time complexity is one reason to be careful. The other one > is the size of the full stack. We have to be careful and do decent > judgement calls here whether the benefits are worth the additional > dependency. Agreed. > Supporting some C++11 features on old compilers is e.g. a case where I > wonder whether adding a dependency for everybody is worth it. Most > compilers (we care about) already support a decent subset of C++11, if you > need other compilers simply don't use the feature. I'm not sure who is the "you" in the above sentence. A maintainer? Or a patch submitter? The choice of the (subset of the) language is a different beast from adopting new libraries. I believe that choices like "C++11 allowed in source code" or "Feature X,Y,Z of C++11 allowed in source code" should be taken by maintainers/Lars, at least for the essentials modules, and published in the wiki. I can't see how else things should be done -- it's a guidance for any random contributor on the way code must be written, and it saves everybody from wasting time using a language feature that is not allowed because of constraints that might not be apparent. -- Giovanni Bajo :: [email protected] Develer S.r.l. :: http://www.develer.com My Blog: http://giovanni.bajo.it
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
