Re: [Interest] QMAKE_COPY not used anymore for files in INSTALLS. Workaround?
This does not seem to be the case. If i try to qinstall an executable that is on a samba share, and currently locked because the result of make install is being run, qinstall fails with "Error copying A to B: Destination already exists" (this error is after the remove() of previous destination file, when QFile::copy fails). In the QFileInfo::exists() in QFile::copy(), the path is still marked as existing, while the app that locks the file is running. But the QFile::remove() seems to have been 'acknowledged', and as soon as the app unlocks the file, it disappears, so i end up without the original nor the new destination file. Hence my need to rename the original destination file before asking for it's removal Le mer. 12 sept. 2018 à 18:15, Thiago Macieira a écrit : > > On Wednesday, 12 September 2018 08:27:04 PDT Olivier B. wrote: > > - Make a renamed backup of the previous target file if it already exists on > > the network share, to avoid some issues (allow to overwrite the installed > > file on the network path, even if some people are currently using that file > > by running the project where it was installed) > > This one shouldn't be needed anymore. The "qinstall" should do this for you by > writing to a temporary file and then doing an atomic rename to clobber the old > file. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QMAKE_COPY not used anymore for files in INSTALLS. Workaround?
On Wednesday, 12 September 2018 08:27:04 PDT Olivier B. wrote: > - Make a renamed backup of the previous target file if it already exists on > the network share, to avoid some issues (allow to overwrite the installed > file on the network path, even if some people are currently using that file > by running the project where it was installed) This one shouldn't be needed anymore. The "qinstall" should do this for you by writing to a temporary file and then doing an atomic rename to clobber the old file. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QMAKE_COPY not used anymore for files in INSTALLS. Workaround?
I do - Reset windows executable permissions for files with some extensions after copy (copied on a network share where executable permission is meaningfull to run the exes), using icacls - Make a renamed backup of the previous target file if it already exists on the network share, to avoid some issues (allow to overwrite the installed file on the network path, even if some people are currently using that file by running the project where it was installed) Sidenote, after some search: Looking at https://github.com/qt/qtbase/commit/50acc8680490319c8fe45615c8d6521f0101728b#diff-2c05a7d11c42aacde5f92861cc595e07, i would say the constraint to have only files of only dirs in COPIES in files_copies.prf can be removed now that the QINSTALL command is the same for files or folders Le mer. 12 sept. 2018 à 17:16, Thiago Macieira a écrit : > On Wednesday, 12 September 2018 07:46:59 PDT Olivier B. wrote: > > Here is another change i noticed when switching from 5.6.2 to 5.11.1 > > > > I used to tweak QMAKE_COPY and its cousins, to do extra stuff on the > files > > installed by INSTALLS variable. > > > > Now, files in INSTALLS are installed using 'qmake -install qinstall', > > stored in QINSTALL variable, written in the makefile directly from a > > hardocded value in qmake sources. > > > > It seems i am able to do something similar that i used to by > > - adding my install targets in COPIES instead of INSTALLS, > > - modifying mkspecs/features/file_copies.prf to use my custom copy > command > > instead of $(QINSTALL) > > > > This has at least the additionnal limitation of forcing me to also split > > install lists that used to contain files and folder into separate lists > > because file_copies.prf does not like it for some reason, even though i > > don't see it doing anything specific for files or folders. Also, i can > not > > add to COPIES, when TEMPLATE=subdirs, when i can do it for INSTALLS > > > > Is there really not anymore a simple way of specifying a list of files > and > > folders to install, using a custom copy command, without modifying qmake > > internals or reinventing the wheel? > > Can you tell us what customisation you needed? There may be a different > way of > doing what you want to do. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > ___ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QMAKE_COPY not used anymore for files in INSTALLS. Workaround?
On Wednesday, 12 September 2018 07:46:59 PDT Olivier B. wrote: > Here is another change i noticed when switching from 5.6.2 to 5.11.1 > > I used to tweak QMAKE_COPY and its cousins, to do extra stuff on the files > installed by INSTALLS variable. > > Now, files in INSTALLS are installed using 'qmake -install qinstall', > stored in QINSTALL variable, written in the makefile directly from a > hardocded value in qmake sources. > > It seems i am able to do something similar that i used to by > - adding my install targets in COPIES instead of INSTALLS, > - modifying mkspecs/features/file_copies.prf to use my custom copy command > instead of $(QINSTALL) > > This has at least the additionnal limitation of forcing me to also split > install lists that used to contain files and folder into separate lists > because file_copies.prf does not like it for some reason, even though i > don't see it doing anything specific for files or folders. Also, i can not > add to COPIES, when TEMPLATE=subdirs, when i can do it for INSTALLS > > Is there really not anymore a simple way of specifying a list of files and > folders to install, using a custom copy command, without modifying qmake > internals or reinventing the wheel? Can you tell us what customisation you needed? There may be a different way of doing what you want to do. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QMAKE_COPY not used anymore for files in INSTALLS. Workaround?
Here is another change i noticed when switching from 5.6.2 to 5.11.1 I used to tweak QMAKE_COPY and its cousins, to do extra stuff on the files installed by INSTALLS variable. Now, files in INSTALLS are installed using 'qmake -install qinstall', stored in QINSTALL variable, written in the makefile directly from a hardocded value in qmake sources. It seems i am able to do something similar that i used to by - adding my install targets in COPIES instead of INSTALLS, - modifying mkspecs/features/file_copies.prf to use my custom copy command instead of $(QINSTALL) This has at least the additionnal limitation of forcing me to also split install lists that used to contain files and folder into separate lists because file_copies.prf does not like it for some reason, even though i don't see it doing anything specific for files or folders. Also, i can not add to COPIES, when TEMPLATE=subdirs, when i can do it for INSTALLS Is there really not anymore a simple way of specifying a list of files and folders to install, using a custom copy command, without modifying qmake internals or reinventing the wheel? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
