Hi,
Yes, it's true that "make install" used to call the GNU install for some files on Unixy platforms, sometimes cp and always copy on Windows. We've changed that in 5.9 to a new built-in command in qmake that should give consistent behavior on all platforms, including the ability to preserve the time stamps. (as you can see, with a mixture of cp, copy and install that was not a given). You should not see any difference when using "make install", but if you do, please file bug reports. Since Qt itself has installs libraries alongside with .so symlinks and those are installed as symlinks, I wonder what the difference is between Qt and your application. Can you compare the command lines generated in the Makefiles? It's true that the internal install command does not support wild-cards. We decided that it is the responsibility of the caller to resolve those (qmake). Or would you like to use this built-in internal command of qmake yourself by calling it directly? Simon ________________________________ From: Development <[email protected]> on behalf of Roland Winklmeier <[email protected]> Sent: Friday, July 21, 2017 12:15:54 PM To: [email protected] Subject: [Development] Behavior change for QMake install targets since 5.9 Dear Qt developers, since 5.9 some of my projects install targets are failing. Investigation has shown that the generated Makefiles reference now a different INSTALL executable. Before it was 'install' from GNU coreutils and now it is calling 'qmake -install qinstall'. Apart from the fact that I could not find anything in the changelog about this bigger change (only a few references that make install will no longer modify the timestamp etc), there are several behavior changes affecting existing install targets. * Installing a symbol link was deep copying the link target under the link name. Example: libfoo.so -> libfoo1.0.0.so<http://libfoo1.0.0.so> Installing libfoo.so installed the binary libfoo.so without creating a symbol link. * Using wildcards to copy several targets is broken. Example: libfoo.so -> libfoo1.0.0.so<http://libfoo1.0.0.so> Installing libfoo*.so fails now. Before it was copying the link and the binary. Maybe the above use cases are not the perfect solution for a specific problem, but they were working. Also there might be other features (or even bugs), users of coreutils install were relying on and are no longer available. Is this considered acceptable since the usage of coreutils install was a private configuration and developers should never rely on its behavior? Cheers R.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
