Hi Zac,
Sorry I read your post very quickly the first time... If your library uses
its own FindPCAP.cmake then you can define an imported target for the PCAP
libraries like so:
# FindPCAP.cmake
find_path(PCAP_INCLUDE_DIR pcap.h ... )
find_library(PCAP_LIBRARY pcap ... )
include(FindPackageHandl
Hello,
In your case, what you need to do is to modify the config file generation
in the library (i. e. you will need to patch the third-party library) so
that the generated config file is relative.
As an alternative, if you do not want to patch the third-party library, try
modifying the generated
Yes, Pau, this is exactly my problem. Or more specifically, as the author
of a library that uses CMake and depends on libpcap, how can I best
structure and distribute the library to make it easy to use (and cross
compile)? I would say using the system libpcap is strongly preferred over
distributin
I had a look at his example, but stopped at the 'export' line. That's
just black magic to me :-)
CMake user package registry? Yikes.
I stopped trying to use cmake for uberbuilds several years ago.
- Dan
On Mon, Oct 19, 2015 at 2:35 PM, Pau Garcia i Quiles
wrote:
> Hi Dan,
>
> On a second read
Hi Dan,
On a second read, it seems Zac's problem was actually finding the
dependency (libpcap) of a dependency. Or rather, making if findable,
because the second depenency contains an absolute path which is broken due
to cross-compilation.
I have never used it but this page contains information o
Well, that's one answer. But if you want to use system libpcap, it's not a
very satisfying one.
It's odd that pcap doesn't ship with a .pc file.
I guess the pcap folks are hostile to pkgconfig because it's LGPL; see
https://github.com/the-tcpdump-group/libpcap/issues/374
- Dan
On Mon, Oct 19,
Hello,
Use ExternalProject to build libpcap as part of your project. Make sure you
use $ORIGIN in rpath everywhere. Install your application (and your bundled
libpcap) to /opt to avoid polluting the system.
On Mon, Oct 19, 2015 at 10:37 PM, Zac Bergquist
wrote:
> Thank you for your reply, Guill
Thank you for your reply, Guillaume.
I understand that this is the expected behavior. I even linked to the
documentation that says this is the expected behavior. What I don't
understand is how to resolve it. Are you saying it is not possible to
create a relocatable package unless all dependenci
Sorry I don't see how this relates to my question?
On Mon, Oct 19, 2015 at 5:33 PM, Owen Alanzo Hogarth
wrote:
> This is the entire project as it stands right now. I have tried changing
> from using relative to more absolute directory names in my project but I
> still get the same build errors.
>
You didn't answer my points b and c, only a.
Am 19. Oktober 2015 18:45:25 MESZ, schrieb Owen Alanzo Hogarth
:
>this is not an in source build.
>
>to do matrix vector multiplication matrix module needs to have access
>to
>the vector class.
>
>
>I'll add the source code for these modules here:
>htt
Thanks for the response, James. Our workaround finally
was to do "make install/fast".
A colleague pointed out that there is a bug report,
https://cmake.org/Bug/view.php?id=15801,
likely related to this.
Is there something about CUDA that requires dependency generation
at build time? (I am used
this is not an in source build.
to do matrix vector multiplication matrix module needs to have access to
the vector class.
I'll add the source code for these modules here:
http://pastebin.com/aj01ycRQ
I think the structure should be a little clearer with all that I've
provided.
This is the prev
Am 19. Oktober 2015 17:33:55 MESZ, schrieb Owen Alanzo Hogarth
:
>This is the entire project as it stands right now. I have tried
>changing
>from using relative to more absolute directory names in my project but
>I
>still get the same build errors.
>
>This pastebin has all the relevant code: htt
This is the entire project as it stands right now. I have tried changing
from using relative to more absolute directory names in my project but I
still get the same build errors.
This pastebin has all the relevant code: http://pastebin.com/BnVTnegP
Anyone can see anything wrong with this?
On Mon
Hello
I'm working on CMake support for Apache Thrift [1].
It is currently already buildable using CMake. However while trying to add
support for generating a ThriftConfig.cmake I ran into some issues
related to cross compilation.
Thrift has the following components relevant to the problem:
C++
Ray
Thanks, removing them from the sub projects didn't cause any issues,
although I am still having the issue with either a no rule to make target
error or if I remove the header I get a linking error:
http://stackoverflow.com/questions/33209659/cmake-no-rule-to-make-target-for-internal-shared-lib
Hi Owen,
On Mon, Oct 19, 2015 at 8:43 PM, Owen Alanzo Hogarth
wrote:
> Also you said the PROJECT() should only be defined once, but shouldn't each
> cmakelists.txt contain a project() or else cmake complains at me.
According to the last paragraph of:
https://cmake.org/cmake/help/v3.0/command/
also one more question.
I have a few header only files one in
common/common_structs.h
and
core_math/core_math.h
These files aren't compiled anywhere, they are just used as header only
files that I will eventually use to link in different versions of the
matrix and vector classes. For example I c
You made a few points that I have not seen before specifically using
$ and
$
Where are these commands, I just did a search and found a mailing list
that said they will override include_directories but I haven't seen
them before, especially in any of the tutorials that i've read on the
cmake site
2015-10-19 13:01 GMT+03:00 Peter Hull :
>
> I have been trying to compile the Allegro library (http://liballeg.org/) on
> Windows 64-bit using Visual Studio 2015.
> I am running into a problem where CMake 3.3.2 doesn't correctly locate the
> 64-bit version of gdiplus.lib.
>
> I've got a minimal exa
Hello,
On 17/10/15 18:28, Michael Jackson wrote:
Are there any known issues with Xcode 6.4 and CMake 3.3.x? I ask because in our
project when we generate the Xcode project we end up with 2 or 3 executables
listed in the drop down combo box. We also end up with lots of duplicate
targets in the
I have been trying to compile the Allegro library (http://liballeg.org/) on
Windows 64-bit using Visual Studio 2015.
I am running into a problem where CMake 3.3.2 doesn't correctly locate the
64-bit version of gdiplus.lib.
I've got a minimal example:
cmake_minimum_required(VERSION 3.3)
find_l
Hi guys
Can I get some help with this question I have. I did a really thorough
writeup here on SO:
http://stackoverflow.com/questions/33209659/cmake-no-rule-to-make-target-for-internal-shared-library?noredirect=1#comment54224377_33209659
--
Powered by www.kitware.com
Please keep messages on-top
23 matches
Mail list logo
