[Interest] [ANN] build2 - C++ build toolchain

Konstantin Tokarev annulen at yandex.ru
Wed Feb 10 20:27:23 CET 2016



10.02.2016, 22:17, "Matthew Woehlke" <mwoehlke.floss at gmail.com>:
> On 2016-02-09 04:04, Diego Iastrubni wrote:
>>  On Mon, Feb 8, 2016 at 11:21 PM, Thiago Macieira wrote:
>>>  qmake's philosophy is "assume everything is there and just use it".
>>>  It's meant mostly for using Qt itself, so you can be sure that all
>>>  of it is present. If you use third-party libraries and they're not
>>>  present, you'll get a compilation error somewhere.
>>
>>  Yes, right. That is why I am probably barking at the wrong tree. I need
>>  CMake support only.
>>
>>  Integrating 3rd party software into Java/ObjC/Swift code is trivial, there
>>  are lots of project handling this. Its very sad that in 2016 we still don't
>>  have something like that can help integrating 3rd party libraries into my
>>  C++ code.
>>
>>  How do you guys integrate 3rd party libraries into your code?
>
> Don't do that. By doing so, you are assuming responsibility for all the
> bugs (especially security issues) of said libraries. Most Linux
> distributions refuse to package any software that bundles third party
> components for this reason (and others, but the security issue is a
> deal-breaker).

That's double-ended sword actually: by using external libraries you take
responsibility for all the bugs present in all releases of these libraries 
except ones you have QA for. Also, in case of Linux distributions they can
apply 3rd party patches to these libraries changing behavior and possibly
leading to bugs in your application.

Also, in many circumstances (embedded systems, stand-alone binary packages)
you just cannot rely on external distributor to fix security bugs for you.

So, unless your goal is to prepare package for particular distro, there is
no certain answer.

>
> Another down side is that I may not want to use the version you are
> trying to bundle. For one, it's superfluous if I already have that library.
>
> The reason you can get away with this with e.g. Java is because it is a
> much more closed ecosystem with a rigidly specified mechanism for
> providing package information (but still has all of the downsides listed
> above). Unfortunately we don't have that for C++ (although properly
> written CMake does a darned good job of coming close).
>
> --
> Matthew
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Regards,
Konstantin



More information about the Interest mailing list