gdalbuildvrt
For gdalbuildvrt it appears that from the docs (and my testing) that one must output the vrt file to the same directory that one calls the command in. Is this correct? And if so, what are the best ways to get around this if I am calling this command in a script?
I think this is incorrect. I have tested all the types of calls using relative paths for the gdalbuilvrt and all the calls succeed.
Even this one works:
.\bin\gdalbuilvrt \export\result.vrt \data\tiff\*.tif
Check that all dependencies are available. The GDAL dll should be in the path or in the same directory as the gdalbuildvrt executable.
You could also use the Dependency Walker to check that all the DLL dependencies are available.
Related
I am creating a cmake package config file (a Foo-config.cmake) for a pre-existing .dll not created by cmake.
The annoying thing is that the .dll depends on some data files.
When a user consumes my package in his own cmake project, I want the INSTALL target to install both the .dll and data files to his specified install location. I don't want him to have to write extra install() rules to do that.
Is it good practice to write the install() rules directly in my Foo-config.cmake? Or is there a better way to do this, maybe with set_target_properties()? I just couldn't find the appropriate property for associating arbitrary file dependencies to a target.
In an alternate universe where this .dll didn't already exist and I had to create it myself using cmake, would I need to create a custom Foo-config.cmake, or is there something in cmake that can automatically generate it for me to achieve the same thing?
FWIW the .dll is an internal legacy library and is normally built by Visual Studio and uploaded in a .zip file to our internal artifactory. I want us to migrate away from manually pulling down .zip files from artifactory and manually integrating the files into Visual Studio projects.
I've since found that there are a couple different ways to do this:
In the config file, simply create one or more variables for the files/dirs you want to install. Then install those using install(FILES) and/or install(DIRECTORY). More info: https://stackoverflow.com/a/46361538/189341
Use file(GET_RUNTIME_DEPENDENCIES). More info:
https://discourse.cmake.org/t/installing-a-pre-built-module-and-its-various-dependencies/5227
How to use cmake file( GET_RUNTIME_DEPENDENCIES in an install statement?
Is it good practice to write the install() rules directly in my Foo-config.cmake?
No.
From 480 *-config.cmake and *Config.cmake files on my system none calls install().
Or is there a better way to do this, maybe with set_target_properties()?
No.
In an alternate universe where this .dll didn't already exist and I had to create it myself using cmake, would I need to create a custom Foo-config.cmake
No. This is unrelated to if you create a .dll or not. If .dll exists, there is no need to create Foo-config.cmake anyway. It is your choice that you want to (or make users to) use find_package.
is there something in cmake that can automatically generate it for me
No.
If you don't intent to support find_package features - VERSION OPTIONAL_COMPONENTS PATHS HINTS CONFIGS etc. - then just go with include(). find_package is just include() with some extra options.
If you want to have install() in your find_package, then just protect it with a variable, like if (FOO_DO_INSTALL) install(....) endif().
I am trying to to compile this ROS package but I get the following error
Could not find a package configuration file provided by "libdlib" with any of the following names:
libdlibConfig.cmake
libdlib-config.cmake
Add the installation prefix of "libdlib" to CMAKE_PREFIX_PATH or set
"libdlib_DIR" to a directory containing one of the above files. If
"libdlib" provides a separate development package or SDK, be sure it has
been installed.
Referencing some other answers on SO and elsewhere, I have added the following lines to CMakeLists.txt
include(/home//src/dlib/dlib/cmake)
include_directories (${dlib_INCLUDE_DIRS})
target_link_libraries(room_segmentation_server ${dlib_LIBRARIES})
I have also installed dlib using these instructions but the error persists.
What am I missing or doing wrong?
First of all: it is way more easy to help you, if you provide your code and the exact error you're facing.
I suppose, that you are trying to find the library with help of find_package(dlib CONFIG)?!
libdlibConfig.cmake is a CMake-File that needs to be provided by your dlib installation. This file has everthing written into it for your cmake, to find the include- and library paths of your dlib-installation. With its help, your cmake then sets the Variables that you're trying to use: dlib_INCLUDE_DIRS and dlib_LIBRARIES (pointing to its corresponding paths).
Therefor that your cmake-call complains, that such a libdlibConfig.cmake couldn't be found, you either do not have such a file on your system, or it is not in the expected directory. In both ways: the variables that you are trying to use, will not be set. Alternatively there might be a FindDlib.cmake-File on your system, that does almost the same, that you could refer to by find_package(Dlib).
If you do not have either of those two file, you need to specify the paths to the include-dir and library-dir on your own:
set(dlib_LIBRARIES "<path to your libdlib.dll>")
set(dlib_INCLUDE_DIR "<path to your dlib/include-folder>")
find_library(LIBDLIB dlib ${dlib_LIBRARIES})
target_include_directories(<your_target> ${dlib_INCLUDE_DIR})
target_link_libraries(<your_target> LIBDLIB)
So coming across a very strange issue with MSbuild using TFS 2015 build definition.
The web application I am trying to build has multiple csprojs that are used as class libraries throughout the application and of course my actual web application.
Bellow are the MSBuild arguments I am passing through currently to get a fully completed build.
/p:UseWPP_CopyWebApplication=True
/p:PipelineDependsOnBuild=False /p:OutDir=C:\Agent\_work\1\s\Application\Package\bin\
/p:WebProjectOutputDir=C:\Agent\_work\1\s\Application\Package\WebSite\
/p:NoWarn=0067
/v:Minimal
What I would actually like to do is the following.
/p:UseWPP_CopyWebApplication=True
/p:PipelineDependsOnBuild=False /p:OutDir=C:\Agent\_work\1\s\Application\Package\Website\bin\
/p:WebProjectOutputDir=C:\Agent\_work\1\s\Application\Package\WebSite\
/p:NoWarn=0067
/v:Minimal
The issue I run in to is after the first assemblies are run and placed in the bin folder it then works on the main webproject csproj and throws a unable to locate file for copy message.
I don't understand why this would be the case? Is it because MSBuild is expecting the bin folder to be empty/not there?
Am I missing something in the build order or different Argument needs to be passed. I have also to tried 'outpath' as well.
In the second arguments, the "OutDir" path is the same with "WebProjectOutputDir". This cause the issue since MSBuild will clean the "WebProjectOutputDir" folder before run "_WPPCopyWebApplication" task which copies files to "WebProjectOutputDir" folder. That means the files generated in "OutDir" during the build will be cleaned because it use the same path with "WebProjectOutputDir", so the task will cannot locate the files to copy.
To avoid this issue, you'd either change the "OutDir" different with "WebProjectOutputDir" or add one more arguments:
/p:CleanWebProjectOutputDir=False
VTK_DIR-NOTFOUND is returned when using CMake. I am using CMake GUI and, as other path errors, I can point then to proper path. However, for VTK doesn't work. I am pointing to directory where VTConfig.cmake file and others are. Also tried with all of other VTK dirs but without any sucess. I am using Visual Studio 12 2013 Win 64 configuration for generation but tried with 2010 too.
pointing to path manually,
The first thing I would check is what is the actual find_package() command being invoked where the error occurs? Perhaps that call is something a bit unusual or explicitly has the MODULE keyword (this would prevent the VTKConfig.cmake file from being found).
If that looks okay, check to see if something is modifying the VTK_DIR variable. Insert the following near the top of your top-most CMakeLists.txt file:
variable_watch(VTK_DIR)
This should tell you what, if anything, is modifying it in ways you didn't expect.
Assuming VTK_DIR is not actually being changed, the next thing you could try is setting CMAKE_PREFIX_PATH to the directory containing the VTKConfig.cmake file (you can add this in the CMake GUI if it isn't there already). Maybe also try variable_watch(CMAKE_PREFIX_PATH) too just in case something is modifying that internally in unexpected was as well.
If that still doesn't reveal anything, then it would seem likely that there is something wrong with either your CMake or VTK installation. Perhaps try an earlier CMake version and see if you get any different behaviour.
Although the currently accepted answer is a good way of debugging, it looks like you're building Point Cloud Library (PCL) with the binaries from unancyowen. In which case I suggest ensuring your system environment variables are setup correctly which will automate the process you are currently going through and facilitate the job of the find_package() methods.
Assuming you installed everything in the same directory (i.e. where you have already linked to FLANN and Eigen) the following default PCL 3rd Party Libraries should be added to Path:
C:\Program Files\PCL 1.7.2\3rdParty\FLANN\bin
C:\Program Files\PCL 1.7.2\3rdParty\VTK\bin
C:\Program Files\PCL 1.7.2\3rdParty\Eigen
C:\Program Files\PCL 1.7.2\3rdParty\Boost
Then Qt, OpenNI etc. which are installed separately.
And you can also add:
BOOST_INCLUDEDIR : C:\Program Files\PCL 1.7.2\3rdParty\Boost\include\boost-X_XX\boost (Replace X_XX with your version number)
BOOST_LIBRARYDIR : C:\Program Files\PCL 1.7.2\3rdParty\Boost\lib
BOOST_ROOT : C:\Program Files\PCL 1.7.2\3rdParty\Boost
EIGEN_ROOT : C:\Program Files\PCL 1.7.2\3rdParty\Eigen
In the field where it is showing that
VTK - DIR : NOT FOUND
You can either copy paste the location or type in, or just browse for the file called VTKConfig.cmake. Generally found inside the build folder of VTK. This is how it solved in my case. Have a try!!
I know that the latest book out on MSBuild says this is not possible, but I am sure I have seen a property that points to the current file.
Does anyone know a way to find the current file? (ie When the main MSBuild file imports a secondary file. What is the path to the secondary file from inside that file.)
I am trying to register my file in HKEY_LOCALMACHINE\Software\Microsoft\VisualStudio\8.0\MSBuild\SafeImports, but the path to the file is not constant on each of my coworkers computers and it is imported from several different projects so doing a hard coded relative path is not a good idea either.
If there is a way to get the current working directory that will work too (the working directory switches with each import and I think I could save it off)
There is not a reliable means to identify the "current file". When MSBuild processes a file it can import several other files, the end result is a single in memory complete representation of the file. When the targets are executing they do not know which file they were declared in.
This is why reusable build scripts must be "parameterized" to accept the location to known relative locations. For example if you have a dependency on the location where your folder for 3rd party references are located, the build script which is driving the process must declare that property for you.
MSBuild 4.0 Only
If you are using MSBuild 4.0, i.e. Visual Studio 2010/.NET 4.0, (which can target .NET 2.0/3.0/3.5) as well. Then you now have these properties which can be used for this specific purpose:
MSBuildThisFile
MSBuildThisFileDirectory
MSBuildThisFileDirectoryNoRoot
Sayed Ibrahim Hashimi
My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build
In 4.0+ you can use properties like $(MSBuildThisFile) to do exactly this. See here