On 13/02/2014 19:44, Bill Hoffman wrote:
HI Bill,
On 2/13/2014 2:23 PM, Bill Somerville wrote:
I would really like to know why it is going wrong with dumpbin in
package generation because using objtool is too slow!
Sounds like a PATH issue. Try getting dumpbin to work from the
command line th
On 2/13/2014 2:23 PM, Bill Somerville wrote:
I would really like to know why it is going wrong with dumpbin in
package generation because using objtool is too slow!
Sounds like a PATH issue. Try getting dumpbin to work from the command
line that you are using.
-Bill
--
Powered by www.kitwa
On 13/02/2014 18:10, Bill Somerville wrote:
Hi,
I have a CMake script that runs on Windows with MinGW Makefiles that
builds the install target OK. It is a Qt GUI application and uses
BundleUtilities::fixup_bundle to pull in and link/rpath prerequisites.
When I build the package target with a
Jc,
That is an approach I have thought about. I even think I have looked at
Slicer for how you work your CMake system.
I prefer to use project-supplied FindLIB.cmake (or a slightly modified
version thereof) because some of them do more than just setting LIBRARY,
INCLUDE_DIR, and FOUND variables.
Hi Rob,
Do address the use case you described, I usually explicitly set the path
the library when built as an external project and rely only on the find_*
command for the use_system case.
See
https://github.com/Slicer/Slicer/blob/c5a39acf7af28ba82cc0097c84d1ebda89cce3b4/SuperBuild/External_teem.c
Hi,
I have a CMake script that runs on Windows with MinGW Makefiles that
builds the install target OK. It is a Qt GUI application and uses
BundleUtilities::fixup_bundle to pull in and link/rpath prerequisites.
When I build the package target with an NSIS packager it looks like the
fixup_bund
When I search for a given library, specifying multiple possible names and
multiple hints for paths...
FIND_LIBRARY( FINDME_LIB
NAMES name1 name2 name3
HINTS path1 path2 path3
DOC "Library to find")
CMake seems to have a preference for name1, and it first searches all HINTS
>
> You are correct that I would prefer that behavior, however I'd prefer to
> go for safety (and do a full clean) until that more advanced logic can be
> implemented... I am in fact using ninja, so hopefully that feature may come
> down the pipe soon :-)
>
If you want a full build, why don't you