On Friday, 21 July 2017 20:40:44 PDT Kevin Kofler wrote:
> Roland Winklmeier wrote:
> > 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 an
Roland Winklmeier wrote:
> 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'.
Would this:
uni
Cristian Adam wrote:
> On Fri, Jul 21, 2017 at 5:48 PM, Phil Bouchard wrote:
>
>> On 07/21/2017 02:10 AM, Lorn Potter wrote:
>>
>>>
>>> On 21 Jul 2017, at 2:22 pm, Phil Bouchard wrote:
So I would like to know if Qt thinks what I am proposing (BB++ -> C++ ->
WebAssembly)
On Fri, Jul 21, 2017 at 5:48 PM, Phil Bouchard wrote:
> On 07/21/2017 02:10 AM, Lorn Potter wrote:
>
>>
>> On 21 Jul 2017, at 2:22 pm, Phil Bouchard wrote:
>>>
>>>
>>> So I would like to know if Qt thinks what I am proposing (BB++ -> C++ ->
>>> WebAssembly) is a good plan.
>>>
>>
>> What does th
On 07/21/2017 02:10 AM, Lorn Potter wrote:
On 21 Jul 2017, at 2:22 pm, Phil Bouchard wrote:
So I would like to know if Qt thinks what I am proposing (BB++ -> C++ ->
WebAssembly) is a good plan.
What does this have to do with Qt?
For a web engine I don't think it's possible to swap the J
On Friday, 21 July 2017 05:17:41 PDT Simon Hausmann wrote:
> 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?
Hi Simon,
Preamble:
The problem I was trying to solve with wildcards was to install a shared
library target into two different directories. The first directory is
installed with a simple 'INSTALLS += target' line. The other path is
installed manually by a second INSTALLS definition and the files a
I was under the impression that
http://code.qt.io/cgit/qt/qtbase.git/tree/qmake/generators/makefile.cpp#n1304
was the code path hit if the entry in foo.files is not a "//real file or
target" (as per the comment a little above).
Simon
From: Development
On Fri, Jul 21, 2017 at 12:17:41PM +, Simon Hausmann wrote:
>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).
>
we did? :}
as much as i despise wildcards in source file lists,
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
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
11 matches
Mail list logo
