[cmake-developers] Future of ccmake and cmake-gui

Eric Wing ewmailing at gmail.com
Thu Aug 17 08:15:24 EDT 2017


> I must be lucky then, because just using macdeployqt copies all the
> dependencies for me and
> updates all the install paths correctly whether I use Qt's own build or
> brew's.

Yes you were.

There are actually multiple problems, not just one.

One problem is release management. Too often I've seen developers ship
a binary that only works on their system because they installed
something and whatever build process didn't catch it. And I've seen
this hapen way too much, even though developers always try to convince
me otherwise. I actually had a conversation with another developer who
was trying to convince me otherwise, and like this one time and the
other developer made the exact mistake like a month later with a
release build. The most public one was ImageMagik. I don't know if it
was Brew, Fink, MacPorts or what, but the general problem is the same.

As for the macdeployqt script, my last stint with Qt was about 2 years
ago. (I seem to have to revist Qt every so many years for different
projects.) At the time, the script seemed to be broken in at least two
places. The first seemed to get borked if you had any library that
used @rpath instead of @executable_path. The second was I think the
script actually missed a bunch of QML plugins (QtQuick) so you would
get failures at launch time or things wouldn't work as expected or
something. I think the Windows script had similar problems. I don't
remember finding a Linux script, but by this point, I had already
learned how to manually assemble my own distribution.

>
> I don't know if you are talking about Chocolatey or Qt but neither require
> Visual Studio on windows.
> Qt even comes with MinGW if you wish.
>
Sorry, I meant my requirement is Visual Studio. MinGW is not a benefit to me.

>> And Mac doesn't have configure/autotools by defaul.
>
> but... "configure" has nothing to do with autotools.
> It's just a shell script (which is sometimes generated *from* autotools;
> this is not the case with Qt AFAIK).

Ah, I stand corrected.


> science can help us here :p two tools are very nice for this :
>
> * bloaty mcbloatface for binary bloat
>
> So there's 17 megabytes of Qt in here; hopefully the rest would already be
> loaded by your system.
>

Thank you for taking the time to write up that analysis. That was
really informative and I learned a bunch of things.

Thanks,
Eric


More information about the cmake-developers mailing list