Alexander Neundorf wrote:
On Monday 11 February 2013, Stephen Kelly wrote:
Alexander Neundorf wrote:
You may also want to cherry-pick
3c84b519260398adef95a0e08f268e93430ccaf9 from my clone to get the
policy warning in the cmake language.
so I branch away from master, pick the patch
Brad King wrote:
try_compile(TCRESULT
${CMAKE_CURRENT_BINARY_DIR}/tcresultbindir
tcresult_src.cpp
TARGETS foo bar
LINK_LIBRARIES foo bar
)
No, for the source form the LINK_LIBRARIES would automatically
handle targets. I just don't want to try doing it with the
Brad King wrote:
Please try to track down and remove any extra pieces like $LINKED
and package_NO_INTERFACES that we added in an attempt to deal with
the previous approach's problems.
Done now in the linked-usage-cleanup branch.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other
Brad King wrote:
Should we create LINK_LIBRARIES now instead, use it in the macros by
directly passing CMAKE_REQUIRED_LIBRARIES to it, and implement the
ignoring of -DLINK_LIBRARIES in that case?
Yes, we can create LINK_LIBRARIES now for the single-source signature and
do nothing yet for
Stephen Kelly wrote:
* Can the INCLUDE_DIRETORIES and COMPILE_DEFINITIONS property avoid
$LINKED:foo references if foo is linked more than once? Skip
appending it if the same reference already exists earlier. In
the BEFORE case, prepend it and remove later instances.
Yes I'm sure that can
Marcus D. Hanwell wrote:
But if you are advising just updating docs, then go for it.
I entirely echo Dave's words here - I thought you meant more of an
active warning against using it at runtime/producing errors.
Well, actually I did mean runtime warnings. The documentation changes
Alexander Neundorf wrote:
On Sunday 17 February 2013, Brad King wrote:
On 2/16/2013 12:32 PM, Alexander Neundorf wrote:
There's another try now in ConfigFileTargetChecks5.
The export-file now warns if a target does not exist, but does not
error out.
I think in light of the discussion
Alexander Neundorf wrote:
On Friday 15 February 2013, Stephen Kelly wrote:
Hi,
FindPackageHandleStandardArgs sets an uppercase found variable, but not
an ExactCase_FOUND variable. This is inconsistent with how config files
work. It also imposes on users the necessity that their FOUND
Alexander Neundorf wrote:
I mean, even if FPHSA would set ExactCase_FOUND always by default, there
still would be no guarantee at all that after a
find_package(Foo)
Foo_FOUND will be set, because as a user of that module I don't know
whether it uses FPHSA or not. I have to read the
Hi there,
I was able to reproduce an earlier build failure on the dashboard:
http://open.cdash.org/viewTest.php?onlyfailedbuildid=2816863
but I've not been able to reproduce this one:
http://open.cdash.org/viewTest.php?onlyfailedbuildid=2817816
I'll not get any chance to fix it this
Brad King wrote:
I think what we need is for the cmTarget::LinkInterface structure
to have a new TargetNames member populated by ComputeLinkInterface
from a new INTERFACE_TARGET_DEPENDS property (better names?).
On export of the link interfaces the net collection of target names
that refer
Brad King wrote:
The new infrastructure will have to somehow treat non-imported
target names as plain library names for its purposes, at least when
invoked through one of the existing check module interfaces.
Thanks for the hint. That was not very difficult.
Now though I have another few
Brad King wrote:
Please fix and add this case to the tests.
I've added fix-automoc-linker-language to stage. Alex, could you review
please?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please
Brad King wrote:
On 02/20/2013 06:51 AM, Stephen Kelly wrote:
Now though I have another few errors I can't reproduce:
All of the Mac 10.8 machines seem to fail like this:
http://open.cdash.org/viewConfigure.php?buildid=2819601
Any idea what's going on?
Thanks,
Steve.
--
Powered
Alexander Neundorf wrote:
On Wednesday 20 February 2013, Stephen Kelly wrote:
Brad King wrote:
Please fix and add this case to the tests.
I've added fix-automoc-linker-language to stage. Alex, could you review
please?
If I see it correctly, actually nothing is done to each target
Brad King wrote:
On 02/20/2013 11:53 AM, Marcus D. Hanwell wrote:
I just pushed generate-export-header-warnings to the stage, this
removes the warnings emitted when the compiler is old. When making
extensive use of generate export headers these warnings only serve to
obscure real warnings,
Hi,
These failures have been occuring since I merged a recent branch extending
the test:
http://open.cdash.org/testDetails.php?test=178135681build=2821141
http://open.cdash.org/testDetails.php?test=178132011build=282
It seems that in cmTargetIncludeDirectories, either
Hi there,
I'm still trying to figure out the appropriate fix for
https://bugreports.qt-project.org/browse/QTBUG-29186
In a previous thread, it was reported that something similar was done with
Qt 4, but it's not clear to me how - FindQt4 and related files don't seem to
do it.
Brad King wrote:
It is the MSYS shell that transforms
/empty5/private
to
D:/msys/1.0/empty5/private
Wow! :) I know 0 about msys.
We can work around this by using two paths so that the ; prevents the
value from looking like a path. See the patch below. From the bottom
hunk
Brad King wrote:
On 02/21/2013 06:42 AM, Stephen Kelly wrote:
I'm still trying to figure out the appropriate fix for
https://bugreports.qt-project.org/browse/QTBUG-29186
In a previous thread, it was reported that something similar was done
with Qt 4, but it's not clear to me how
comicfans44 wrote:
Hello everyone , I use CMake to build a qt4 project,
I found after this commit
ec85306025ae787e08d4ce097fde966f1809c74f
Merge topic 'tll-includes-defines'
re-run cmake of my project gives segmentfault.
Hi there,
Thanks for the report. Please try with the master
comicfans44 wrote:
Hello everyone, I use cmake(git master) to build llvm source . and found
this commit
hopes this can help improving CMake
Thanks for the report. In particular, the commit
a1c4905f723f9d99bd481580f9fe24fdaf81b174 'Use the link information as a
source of compile
Brad King wrote:
On 02/21/2013 12:34 PM, Stephen Kelly wrote:
I'll change the test as described.
Now that the interface-property-external-read topic is clean
please rewrite/cleanup the topic history. I just cleaned up
the try_compile-targets topic history but the other one
Brad King wrote:
Can't you instead simply have the usage requirements skip appending
a target's own requirements to itself? That way the resulting
generator expression would still not have a self reference.
Yes, but I only realized that after replying to the rest of the mail :).
As it has
comicfans wrote:
for the last try (git master in Friday morning), there is no such
problem(only llvm config slow down). when digging that, I checkout old
git version and found this one. so this problem may be resolved in
following commit. sorry for this misleading report.
Great, case closed!
Stephen Kelly wrote:
comicfans44 wrote:
Hello everyone, I use cmake(git master) to build llvm source . and found
this commit
hopes this can help improving CMake
Hi,
I pushed a commit to fix this issue. Please try it out by using the next
branch instead of the master branch.
Thanks
Brad King wrote:
, so I don't know if TARGET_PROPERTY should be
changed too. If it is, then it makes sense to change TARGET_DEFINED to
consider utilities to not be targets, as that expression is most usefully
used with TARGET_PROPERTY.
Perhaps TARGET_DEFINED is not a good name then. What
Hi,
CMAKE_LINK_DEPENDS_NO_SHARED was introduced in this cycle, but off by
default. It seems useful enough to be on by default. Is there any reason not
to enable it by default?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
Brad King wrote:
If the option were to be on by default then instead there
should be the reverse option off by default with a name like:
CMAKE_LINK_DEPENDS_SHARED_LIBRARIES
I implemented that but one of the dashboards already fails:
Brad King wrote:
On 02/25/2013 03:09 PM, dlrd...@aol.com wrote:
Can you elaborate on some of the theoretical cases where relinking
will be needed but no header files have changed? It would be useful
to have them available for discussion.
I can think of one, but it’s probably not that
Brad King wrote:
On 2/25/2013 5:18 PM, Matthew Woehlke wrote:
The possibility that first came to mind is where the API depends on
compiler flags or similar preprocessor-ish bits, especially if these are
not well guarded with something like a configured config.h to change
when these change
Hi,
I've been working on the JOIN genex in my join-genex branch and encountered
some generic issues along the way relating to use of lists with generator
expressions. I don't propose merging the JOIN feature for the next release,
but there seems to be remaining issues which would be best
Brad King wrote:
On 02/27/2013 08:31 AM, Stephen Kelly wrote:
but there seems to be remaining issues which would be best solved in
2.8.11.
$1:foo_target;bar_target
I'm hitting problems of conflicting requirements though, when used with
add_custom_command, and I'm not certain what
Brad King wrote:
The argument splitting rule should remain simple: a quoted
argument is one value and an unquoted argument expands on ;.
What your topic needs to do is delay the expansion for unquoted
generator expressions from configure to generate time.
The problem is that by the time the
Brad King wrote:
On 02/27/2013 04:37 PM, Alexander Neundorf wrote:
1) we should continue to recommend to use the variables (which will now
be set to the name of the target). In case of typos, this will lead to an
empty variable (as it did before with Find-modules), and undefined
references
Brad King wrote:
On 02/27/2013 01:24 PM, Brad King wrote:
The argument splitting rule should remain simple: a quoted
argument is one value and an unquoted argument expands on ;.
I didn't realize it before, but this seems to already be the case, right (in
a world without genexes)?
On 03/04/2013 02:58 PM, Brad King wrote:
Stephen,
We originally wanted to start the 2.8.11 release candidate series at
the end of January. We've delayed it while your usage requirements
feature has cooked. Even last week you were polishing up a few subtle
corrections, so it was worth the
Alexander Neundorf wrote:
did you get around to add handling for usr-move to the relative directory
references for exports-files ?
Otherwise I'll see whether I find time this week.
I didn't work more on that, no, as I wrote here:
Stephen Kelly wrote:
So, I think it's mature enough for release now, yes.
It might be worth documenting it a bit more prominently though...
Any opinion on this?
Thanks,
Author: Stephen Kelly steve...@gmail.com
Date: Tue Mar 5 23:01:22 2013 +0100
Mention that IMPORTED targets may
Alexander Neundorf wrote:
You may have already realised that, for the same reason, I didn't work
more on this stuff either:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6106/focu
s=6161
That branch was just a proof of concept.
Oh, ok, here I assumed you would have
Alexander Neundorf wrote:
The patch only avoided that specific situation when it occured with
automoc, but the same situation can also happen independent from automoc.
Not really, the attached case can only crash because of the automoc support
built-in in cmake. Can you create a testcase
Stephen Kelly wrote:
Alexander Neundorf wrote:
The patch only avoided that specific situation when it occured with
automoc, but the same situation can also happen independent from automoc.
Not really, the attached case can only crash because of the automoc
support built-in in cmake. Can
Brad King wrote:
On 03/11/2013 07:01 PM, Stephen Kelly wrote:
Stephen Kelly wrote:
Alexander Neundorf wrote:
The patch only avoided that specific situation when it occured with
automoc, but the same situation can also happen independent from
automoc.
Not really, the attached case can only
Brad King wrote:
On 03/12/2013 06:30 PM, Brad King wrote:
On 03/12/2013 06:08 PM, Alexander Neundorf wrote:
My AutomocFixWithoutQt branch basically reverts the first commit, so
automoc is now again only one step, without the temporary vector of
targets, without needing additional checks. In
Matthew Woehlke wrote:
If I turn off BUILD_TESTING, I get this error:
CMake Error at Tests/CMakeTests/CMakeLists.txt:7 (add_test):
Error evaluating generator expression:
$TARGET_FILE:cmsysTestsCxx
No target cmsysTestsCxx
Call Stack (most recent call first):
Brad King wrote:
On 03/13/2013 02:09 PM, Stephen Kelly wrote:
If I turn it on, it works. So it seems as though something is not fully
respecting BUILD_TESTING?
git-bisect tells me
e03f83f394c53acbcc9dcff03f189170b2f33322 is the culprit (ProcessorCount
test: fix path to cmsysTestsCxx
Matthew Woehlke wrote:
target_include_directories(foo PUBLIC
$BUILD_INTERFACE:${Foo_BINARY_DIR}
$INSTALL_INTERFACE:${CMAKE_INSTALL_PREFIX}/include
)
...with Ninja, the include directive passed to the compiler is '-I.'
The '-I.' shouldn't be a problem. I've just tested on linux and it
Brad King wrote:
On 03/14/2013 01:43 PM, Alexander Neundorf wrote:
Would you object a check that if a target has at least one C or Fortran
source file, but no C++ source file, it should skipped for automoc ?
I was thinking about that approach too. Basically if the target
has at least one
Alexander Neundorf wrote:
yes, and I think it's a bug (caused by me).
If I was a cmake user and not a developer, I would file a bug report if I
would find out that my helloworld.c suddenly links again libstdc++.so
My point was that a policy is still needed anyway.
Thanks,
Steve.
--
Powered
Matthew Woehlke wrote:
...then I get 'hello;$INSTALL_INTERFACE:world;left'.
Is this expected/correct?
Nope, this is a bug.
Thanks for testing/reporting. I've pushed a fix to the next branch. Please
try that out.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware
Matthew Woehlke wrote:
On 2013-03-14 16:46, Stephen Kelly wrote:
Matthew Woehlke wrote:
...then I get 'hello;$INSTALL_INTERFACE:world;left'.
Is this expected/correct?
Nope, this is a bug.
Thanks for testing/reporting. I've pushed a fix to the next branch.
Please try that out
I have a fix for it coming soon.
Steve, you have your Qt5 in CMAKE_PREFIX_PATH, right? That's a way I
found to reproduce this.
Yes, that's right.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
clin...@elemtech.com wrote:
- Original Message -
I have a fix for it coming soon.
Steve, you have your Qt5 in CMAKE_PREFIX_PATH, right? That's a way I
found to reproduce this.
Yes, that's right.
Ok. Then the fix is now in next.
Tested and it works for me,
Hi there,
I applied my patch to kdelibs to use the INTERFACE_INCLUDE_DIRECTORIES of
targets and remove include_directories() calls.
This resulted in a failure when moc'ing for dfaure:
http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/7778/focus=7779
In his system, he has Qt 4 headers
Stephen Kelly wrote:
find_package(Qt5Test)
Something like this is also needed to reproduce without patching Qt:
# Temporary until upstream does this:
foreach(_component Core Test)
if (TARGET Qt5::${_component})
set_property(TARGET Qt5::${_component}
APPEND PROPERTY
Stephen Kelly wrote:
The bug can be reproduced with this cpp file:
#include QtTest/QTest
// Make CMAKE_AUTOMOC run on this file.
class MyObject : public QObject
{
Q_OBJECT
explicit MyObject(QObject *parent = 0)
{
QSKIP(The QSKIP macro has two args in Qt4 and one in Qt5
Stephen Kelly wrote:
I recommend changing AUTOMOC to do the same appending. At some point, it
seems that was done
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5293/focus=5297
but a followup branch probably changed that to the current state.
I've pushed the automoc
Alexander Neundorf wrote:
The comment to your commit is not really correct.
The commit d2536579 (Automoc: fix regression #13667, broken build in
phonon, 2012-11-19) changed Automoc to try to re-add the Qt header dir
if it was stripped out as an implicit include from the moc command
line.
Brad King wrote:
On 03/18/2013 07:24 PM, Stephen Kelly wrote:
Alexander Neundorf wrote:
The comment to your commit is not really correct.
The commit d2536579 (Automoc: fix regression #13667, broken build in
phonon, 2012-11-19) changed Automoc to try to re-add the Qt header dir
Alexander Neundorf wrote:
What I actually propose would look something like
install(TARGETS KArchive EXPORT KArchiveTargets NAMESPACE KF5::
...
INCLUDES DESTINATION $INSTALL_PREFIX/${INCLUDES_INSTALL_DIR}
)
so it could be folded into INSTALL_TARGETS_DEFAULT_ARGS. I don't know if
Hi,
When the try_compile source-file signature is used, it generates a
cmake_minimum_required line with the version of cmake run by the user (not
the minimum used by the project being built).
This affects policies, and could have an effect on the generated
CMakeLists.txt file. Anyone using
Alexander Neundorf wrote:
With PUBLIC, PRIVATE and INTERFACE,
directories can be added to the wrong one (i.e. PUBLIC instead PRIVATE or
INTERFACE) and it will still build, but the interface will be bigger than
necessary.
Would it be reasonable to issue an error at install(EXPORT)-time if
Stephen Kelly wrote:
We already have similar errors in the exported targets files for
things like missing library files. The wording says something about
possible missing or broken packages.
Right, I'll see if I can do something similar over the next few days.
I've pushed the error
Brad King wrote:
On 03/25/2013 05:57 AM, Stephen Kelly wrote:
Stephen Kelly wrote:
I've pushed the error-on-exported-missing-include-dir branch to my
clone.
Why does the test need CMAKE_OMIT_INCLUDES_CHECK?
Without it I get
Target testSharedLibRequired INTERFACE_INCLUDE_DIRECTORIES
Brad King wrote:
On 03/25/2013 01:41 PM, Brad King wrote:
So will I squash these commits together and push to next?
Yes, if this is intended for 2.8.11-rc2.
I just looked at the change merged to next. Can you please add
test cases for the error messages?
Done now, thanks,
Steve.
--
Brad King wrote:
On 03/26/2013 02:53 PM, Robert Maynard wrote:
My concern with this feature is the use case of a directory not existing
at configure time, but which will exist at linking time. Primarily this
would occur when an imported library is the result of an
add_custom_command call
Brad King wrote:
Additionally I've added a commit to
my clone in the error-on-exported-missing-include-dir branch, which
introduces a policy. That commit doesn't really have to be in CMake
2.8.11. Currently the test doesn't pass, and I'm not sure why. The
cmake_policy() line in the test
Brad King brad.king@... writes:
On 02/20/2013 03:57 PM, Alexander Neundorf wrote:
On Wednesday 20 February 2013, Brad King wrote:
Alex, does this do what you want?
Looks good.
But shouldn't the IMPORTED_LINK_DEPENDENT_LIBRARIES libs be also taken into
account ?
I think so, so
Brad King wrote:
On 03/27/2013 08:54 AM, Stephen Kelly wrote:
Brad King brad.king@... writes:
the iface-SharedDeps list needs to be included in
IMPORTED_LINK_INTERFACE_TARGETS_≤CONFIG also.
The problem with this is that it will break working code. Not-found
entries
Brad King wrote:
The Qt5::Script entry in IMPORTED_LINK_DEPENDENT_LIBRARIES_CONFIG will
be skipped by cmComputeLinkInformation::AddSharedDepItem if it is not an
available target name because it is not a full path.
When generating the Qt5 imported targets if you know dependencies will
be in
Brad King wrote:
Alex, Steve,
I just made this automoc change:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=20c99b1d
in response to discussion here:
http://www.cmake.org/Bug/view.php?id=13900#c32710
In addition to working around a VS 2012 bug, it also makes projects
look
Marcus D. Hanwell wrote:
Hi,
I was updating my machine earlier today, and wanted to build the
latest CMake master (00ef90). I am using Arch Linux with Qt 4 and Qt 5
installed. If I compile with qmake-qt4 then I see the following
compile failure,
[ 88%] Generating qrc_CMakeSetup.cpp
Stephen Kelly wrote:
Marcus D. Hanwell wrote:
Hi,
I was updating my machine earlier today, and wanted to build the
latest CMake master (00ef90). I am using Arch Linux with Qt 4 and Qt 5
installed. If I compile with qmake-qt4 then I see the following
compile failure,
Please also try
Marcus D. Hanwell wrote:
My other question is - are we forcing Qt 5 when available over Qt 4
for the CMake Qt dialog?
If Qt 5 is available then it is preferred, yes. Until recently, that was the
only way possible.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware
Brad King wrote:
On 04/04/2013 06:36 AM, Stephen Kelly wrote:
Please also try the workaround-usr-move-qt5 branch on stage.
Even with that we still get:
http://open.cdash.org/viewBuildError.php?buildid=2865930
because there is no //bin/moc.
Interesting. Can you say more about what
Hi,
A new Qt CI machine machine is hitting problems with the CMake unit tests:
http://thread.gmane.org/gmane.comp.lib.qt.devel/10746
Any idea what the problem could be there?
Thanks,
Steve
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
Laszlo Papp wrote:
Hi,
Just found this post from Brad:
http://www.cmake.org/pipermail/cmake/2011-February/042556.html
I would suggest to improve the warning message. It is not exactly clear
why that happens to a user like me.
My colleague saw this warning in his cmake output when he was
-October/024701.html for example.
I don't know anything about building on Windows, so that might indeed be
the problem. Can you confirm that it's not a misunderstanding?
Thanks,
Steve.
*From:* Stephen Kelly
*Sent:* Wednesday, April 10, 2013 4:03 AM
*To:* cmake-developers@cmake.org
Hi
Eric Noulard wrote:
I don't know anything about building on Windows, so that might indeed be
the problem. Can you confirm that it's not a misunderstanding?
In http://thread.gmane.org/gmane.comp.lib.qt.devel/10746 we can read:
3-- Build started: Project: axserverapp, Configuration:
Stephen Kelly wrote:
So, how is the target 32bit/64bit determined? An option to cmake at cmake
time?
It seems to be determined by the generator:
http://stackoverflow.com/questions/3785976/cmake-generate-visual-studio-2008-solution-for-win32-and-x64
I'll figure out a way to determine
clin...@elemtech.com wrote:
It appears it needs more logic to handle the CMAKE_GENERATOR variable.
If a visual studio generator is going to be used, then it'll probably need
logic to determine which version of visual studio it is to choose the
correct visual studio generator (because of
Bill Hoffman wrote:
On 4/10/2013 11:54 AM, Stephen Kelly wrote:
(at the very bottom)
http://testresults.qt-project.org/ci/QtBase_stable_Integration/build_00894/win64-msvc2012_developer-build_qtnamespace_Windows_8/log.txt.gz
Any ideas?
I think you want this generator:
Visual Studio 11
Bill Hoffman wrote:
Seems a bit unstable to hard code the version. I wonder if you can
detect the one that is being used somehow?
I don't think it's unstable, but I do think the version and arch should be
detected somehow.
Would it be possible for cmake to run devenv to check the version
Stephen Kelly wrote:
Bill Hoffman wrote:
Seems a bit unstable to hard code the version. I wonder if you can
detect the one that is being used somehow?
I don't think it's unstable, but I do think the version and arch should be
detected somehow.
Would it be possible for cmake to run
Bill Hoffman wrote:
What about VS 9, seems to be missing?
The Qt CI system only tests 2010 and 2012:
http://testresults.qt-project.org/ci/QtBase_dev_Integration/latest-success/
The wince70embedded-armv4i-msvc2008_Windows_7 build is currently failing for
other reasons, but it's a
Hi,
This is mostly just feedback on some experience with cross-compiling.
As part of trying to figure out to what extent Qt 5 needs to be patched to
solve the kind of issue raised in
http://public.kitware.com/Bug/view.php?id=14041
and fixed in 6c613b433c45efb0bb013a6bd668cbb8ac740259, I've
Brad King wrote:
On 04/10/2013 07:41 PM, Stephen Kelly wrote:
I also need to
set(CMAKE_EXTRA_SHARED_LIBRARY_SUFFIXES .so.1)
to tell CMake that libz.so.1 is a shared library, otherwise it gets
ignored.
So, for feedback, it seems like it might make sense to automatically
treat
Stephen Kelly wrote:
However, the Raspberry Pi has libz.so in some funny locations:
stephen@hal:~/rpi/rasp-pi-rootfs$ find -name *libz*
./lib/arm-linux-gnueabihf/libz.so.1
./lib/arm-linux-gnueabihf/libz.so.1.2.7
./usr/lib/arm-linux-gnueabihf/libz.so
./usr/lib/arm-linux-gnueabihf/libz.a
Stephen Kelly wrote:
This doesn't affect only Qt, but could affect any CMake user trying to use
a library which depends on zlib on the Raspberry Pi.
Actually I notice that I have a similar situation on my ubuntu system:
/lib/x86_64-linux-gnu/libz.so.1
/lib/x86_64-linux-gnu/libz.so.1.2.7
Stephen Kelly wrote:
I guess it works because libz.so and libz.so.1 are both in system paths?
But then why doesn't the same work on the Raspberry Pi cross compile? The
CMAKE_LIBRARY_ARCHITECTURE is already determined to be arm-linux-gnueabihf
there.
I found out what the problem is. CMake
Alexander Neundorf wrote:
I think that's a good idea.
Qt, once built, knows where the compiler is and what the target operating
system is, so it is a good source of information for that.
It also knows at least some part of CMAKE_FIND_ROOT_PATH, that would be
its own install locations, maybe
Alexander Neundorf wrote:
On Monday 15 April 2013, Stephen Kelly wrote:
Alexander Neundorf wrote:
I think that's a good idea.
Qt, once built, knows where the compiler is and what the target
operating system is, so it is a good source of information for that.
It also knows at least some
Alexander Neundorf wrote:
On Friday 12 April 2013, Stephen Kelly wrote:
I found out what the problem is. CMake doesn't add the sysroot to the
link line, so that's why the linker is not finding the library. It was
searching in my native root and not finding them.
set(CMAKE_CXX_LINK_FLAGS
Brad King wrote:
On 04/16/2013 10:41 AM, Stephen Kelly wrote:
That means that the include directories of an upstream package will have
to prefix each path with ${CMAKE_FIND_ROOT_PATH} in order to be useful
in both cross compiling contexts and
non-cross-compile-but-direct-on-target contexts
Alexander Neundorf wrote:
On Monday 15 April 2013, Stephen Kelly wrote:
Alexander Neundorf wrote:
..
Is hostprefix somewhere in lib/ ?
No. It's specified when configuring Qt. See the paragraph above.
So it's SomePrefix/cmake/ ?
I think it belongs into somewhere in lib/, since its
Alexander Neundorf wrote:
set(Qt5Gui_EGL_INCLUDE_DIRS
${CMAKE_FIND_ROOT_PATH}/opt/vc/include
${CMAKE_FIND_ROOT_PATH}/opt/vc/include/interface/vcos/pthreads
${CMAKE_FIND_ROOT_PATH}/opt/vc/include/interface/vmcs_host/linux
)
In general CMAKE_FIND_ROOT_PATH is a list, then this would be a bug.
Alexander Neundorf wrote:
On Monday 15 April 2013, Stephen Kelly wrote:
Alexander Neundorf wrote:
..
Is hostprefix somewhere in lib/ ?
No. It's specified when configuring Qt. See the paragraph above.
So it's SomePrefix/cmake/ ?
I think it belongs into somewhere in lib/, since its
Hi,
as 2.8.11 will be out soon, I'm returning to some pending features I'd like
to get in early in the next release.
I've pushed the genex-evaluate-file branch to my clone. It implements the
file(EVALUATE) subcommand, which evaluates an input file containing
generator expressions and writes
Hi,
I've (force) pushed the join-genex branch to my clone. It implements the
generator expression
$JOIN:list,sep
such that the result is
sepelement1sepelement2...sepelementN
This is part of the work to make it possible to refer to properties of
targets before the target is defined:
Alexander Neundorf wrote:
On Tuesday 23 April 2013, Stephen Kelly wrote:
Hi,
as 2.8.11 will be out soon, I'm returning to some pending features I'd
like to get in early in the next release.
I've pushed the genex-evaluate-file branch to my clone. It implements the
file(EVALUATE
701 - 800 of 3503 matches
Mail list logo
