Clinton Stimpson wrote:
Yeah, I understand that is the issue.
I don't quite get what is new for Qt 5.1. I thought Qt 4.x only installed
Qt headers inside the framework too. Perhaps its new from 5.0 to 5.1?
Yes.
On a Mac with a prebuilt Qt 4.7
qmake -query QT_INSTALL_HEADERS =
On Tuesday, July 02, 2013 05:12:00 PM Stephen Kelly wrote:
Clinton Stimpson wrote:
Yeah, I understand that is the issue.
I don't quite get what is new for Qt 5.1. I thought Qt 4.x only installed
Qt headers inside the framework too. Perhaps its new from 5.0 to 5.1?
Yes.
On a Mac
Clinton Stimpson wrote:
As a feature, would it make sense to make that unnecessary in a future
CMake version?
How would you make it unecessary?
Would you change CMake so the include directory would automatically be
included for frameworks specified in target_link_libraries()? That does
On 07/01/2013 09:17 AM, Stephen Kelly wrote:
However, a colleage tested it (I have no Mac to hand), and told me that if
those relevant lines are removed from the Config files, CMake does not seem
to pass the relevant -F and --framework lines to the compiler, so #includes
do not work.
Is
Brad King wrote:
On 07/01/2013 09:17 AM, Stephen Kelly wrote:
However, a colleage tested it (I have no Mac to hand), and told me that
if those relevant lines are removed from the Config files, CMake does not
seem to pass the relevant -F and --framework lines to the compiler, so
#includes do
On 7/1/2013 10:08 AM, Stephen Kelly wrote:
What path actually should be in the IMPORTED_LOCATION in order for the
framework to be handled correctly?
I don't remember for sure off the top of my head, but I think that
the automatic -F options work when the path is /path/to/foo.framework
but
On Monday, July 01, 2013 11:11:58 AM Brad King wrote:
On 7/1/2013 10:08 AM, Stephen Kelly wrote:
What path actually should be in the IMPORTED_LOCATION in order for the
framework to be handled correctly?
I don't remember for sure off the top of my head, but I think that
the automatic -F
Clinton Stimpson wrote:
With the refactor IMPORTED_LOCATION in generated export files went from
/path/to/foo.framework/foo
to
/path/to/foo.framework/Version/A/foo
That change naturally came out of the refactor.
Since for non-frameworks, the property is the location of the actual file
Clinton Stimpson wrote:
This change hasn't been released yet and will go into CMake 2.8.12.
Ah, I see. I was mis-reading my gitk.
If Qt were to put multiple versions of libraries into one framework, then
I think the IMPORTED_LOCATION should be more specific.
The issue is more about
On 7/1/2013 1:21 PM, Clinton Stimpson wrote:
This change hasn't been released yet and will go into CMake 2.8.12.
As far as I know, it really doesn't matter which of the 2 you use for
IMPORTED_LOCATION as they both work.
To clarify:
* Clinton is talking about what IMPORTED_LOCATION values the
On Monday, July 01, 2013 07:36:24 PM Stephen Kelly wrote:
Clinton Stimpson wrote:
This change hasn't been released yet and will go into CMake 2.8.12.
Ah, I see. I was mis-reading my gitk.
If Qt were to put multiple versions of libraries into one framework, then
I think the
11 matches
Mail list logo
