After installing cmake-3.8.1-win64-x64 I got thisenter image description here
So what can I do with this? Thanks.
cmake-gui does not help you create cmake configuration files, it parses these files to generate and configure projects.
In your source code directory, you should have a CMakeLists.txt file which defines the rules for CMAKE to configure your problem. That directory should be entered into the first box.
Next, you get to decide where to build the binaries. We could do it in the source directory, but the generated artifacts could pollute what is already there. "Cleaning" the build by deleting all of those artifacts while keeping the original sources is tedious at best, so it's a good idea to make an empty directory and use that as your binaries path.
Once you have those fields entered, you should be able to "Generate" or "Configure" your project. If you need help creating a CMakeLists.txt file (that's really the complicated part), then check out their tutorial.
Related
I've just installed Golang on my machine, and I set up GOPATH.
But when I navigate to my go/src I see that src folder contains ./sourcegraph.com, ./golang.org and ./github.com. Also GOPATH/bin and GOPATH/pkg also no empty.
So I have several questions:
1) I know how to use ./github.com folder for pushing my code to github, but why it contains , from box, some other not mine projects inside such as acroca, cweil ... and other ? Can I clear this folder?
2) What I should do with golang.org folder, can I remove it ?
3) What I should do with sourcegraph.com folder, can I remove it ?
4) Can I clear bin and pkg from preinstalled binaries and packages?
I think you not only installed the Golang but also install/configure Visual Studio Code IDE with Go Extension. Those alien repositories were created when the extension installs needed tools. The full list of tools can be found here. Or probably other similar IDE/extension which depends on those tools.
Yes you can clear the sources, since the IDE depends only on the compiled binary, and the sources are only needed during compilation.
Same as (1). Refers to Golang SubRepositories
Same as (1)
For now, you can clear the content of pkg directory but don't remove the directory. In the future, when you install some packages/libraries, the compiled version may be created under the directories, so don't remove it. For bin directory, don't remove the files inside it, because the IDE (Go Extension) depends on them.
But, since I don't know exactly what else you've done, I think before you completely remove them, try just to move them outside your GOPATH or take a backup and see whether your dev environment works as expected.
For my thesis I want to use Dlib's face_landmark_detection, but I keep running into these errors (for both Visual studio 2013 as well as 2015):
"cannot open include file: 'zlib.h': No such file or directory"
and
"'F77_INT': undeclared identifier".
It repeats itself so I have 36 errors based on these two problems.
My supervisor has given me some steps to follow to set up the project:
add dlib-master and dlib-master\examples to VC++ directories -> include directories
add dlib-master\dlib\external\libjpeg and dlib-master\dlib\entropy_decoder to C/C++ -> General -> Additional include directories
add all folders and items from dlib-master\dlib\external (cblas, libjpeg, libpng and zlib) to the project source folder
add the dlib source file (from dlib-master\dlib\all) and add face_landmark_detection (from dlib-master\examples) to the project source folder.
and according to him this has worked on every other computer so far, but on my laptop it just won't. We checked to project, but zlib.h is in the zlib folder in the project. Does anyone here have an idea on what might be going wrong?
If I didn't give enough info, please ask. I don't know what else might be needed to solve this.
I have just come about this same problem and wanted to post my solution since I have found so much conflicting documentation on the subject.
The folder containing the dlib folder as well as the libpng, libjpeg, and zlib folders from dlib/external need to be added to the additional include directories list in the solution settings.
dlib/all/source.cpp as well as the source files for libpng, libjpeg, and zlib also need to be added to the project.
Note that CBLAS should not be added to the project in any way, because it needs Fortran to compile, and it is very difficult to get this to compile from Visual Studio.
Finally, make sure to add DLIB_PNG_SUPPORT and DLIB_JPEG_SUPPORT as preprocessor defines in the project settings.
I also attempted to use a cmake generated solution, however, for some reason it had trouble with png support.
It is probably easiest to use CMake to configure your project which uses dlib. It avoids setting all those paths manually. During CMake configure step you can disable usage of libraries like zlib which you don't have/want/need. Here is an example CMakeLists.txt which works for me:
cmake_minimum_required(VERSION 2.6)
PROJECT(DatasetClassifier CXX C)
set(dlib_DIR "" CACHE PATH "Path to dlib") # http://dlib.net/
include(${dlib_DIR}/dlib/cmake)
ADD_EXECUTABLE(DatasetClassifier DatasetClassifier.cpp)
TARGET_LINK_LIBRARIES(DatasetClassifier ${dlib_LIBRARIES})
I'm working on my first project using cmake, and for the most part it's been going well but I've run into one problem I can't figure out.
Let's say I have my CMakeLists.txt file located at ~/project/build. I would like for the output from cmake (not the binaries, but the makefile/configuration files) to be independent of where I run cmake from.
As an example, if my terminal is sitting in the ~/project/build directory, calling cmake ~/project/build creates the makefile and everything else within the ~/project/build directory. This is the behaviour that I'd like. If I call cmake ~/project/build from anywhere else, it creates the makefile and everything else in whatever directory the terminal called the program from.
Is it possible to force cmake to generate its makefile and associated files in the same folder as the CMakeLists.txt file? I've taken a look through the documentation and I've had no problems figuring out how to change binary output directories, but I can't really find any mention of what I'm trying to do.
I realize this is a pretty minor annoyance (it's not that hard to move into my build folder before building the project) but I'm just wondering if it's possible and if there's some reason it wouldn't be advised.
You have to use 2 commands for this
1) cmake -B "Dest path(Any path in which u want to generate the output files)" -H"Source path(root CMakeLists.txt path)"
2) cmake --build "Dest path"
I have a project organized as follows:
include/
src/
share/myprogram/
where share/myprogram/ contains resources.
My program is accessing these resources using relative paths. The executable expects to find them in ../share/myprogram/.
I would like when I run:
mkdir build
cd build
cmake ..
make
to have the following to happen:
make a bin directory
compile and put the executable in bin/
copy the share directory in the build directory
I am looking for a clean way of doing this. Ideally, I would like CMake to be aware of the resources as resources.
I know that I could use a copy custom command. Is this the only way to achieve this?
Bonus
If the resources could appear under Resources in Xcode when using the Xcode generator, and the copy be a clean copy phase under the mybin target, that would be awesome (and that's what I mean by CMake being aware of the resources as resources.)
Update:
What I have thus far:
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/bin)
add_executable(mybin ${Headers} ${Sources})
add_custom_target(
Resources ALL
${CMAKE_COMMAND} -E copy_directory ${PROJECT_SOURCE_DIR}/share ${PROJECT_BINARY_DIR}/share
SOURCES ${Resources}
)
You may use Configure_file for copying files from source dir to binary dir. it has parameter Copyonly.
I am doing a unix command line tool, I am not doing a Mac OS X bundle and Xcode's resource folder is only for bundle resources so forget the bonus.
I realized that I wasn't doing things correctly.
Using a relative path to access a resource is not reliable since the program can be executed from anywhere.
What I did is to look for resources in a hierarchy of folder, starting from user specified, to environment variable, to relative directories and finally to standard unix directories.
So actually, the copy phase during the build is not necessary anymore. Only the installation matters and that is fairly easy:
install(DIRECTORY share/ DESTINATION share)
FYI, I kept my custom_target as is since I like having resources visible in Xcode, and calling it Resources makes it pretty :)
I have a project which has been checked out of Subversion and uses Scons for building. However, I have a library installed on my computer which Scons doesn't detect - it just says that the include file can't be found. Is there any way that I can direct Scons to the library location without altering the Sconscript file at all (because I don't want to have to deal with conflicts every time I update) - e.g. add a command line option that it will detect before searching for the include file? I can't even see all the available options because it doesn't respond to the --help option before it searches for the include files.
Okay, after some more googling, I found that there is a way to do it. gcc has a number of default directories that it searches (which I already knew - I just didn't know what they were defined as). The simplest way to do what I was after is to add the directories to these environment variables. The one that I needed was
$CPATH
This sets the path where gcc searches for its include files. Setting this to the directory I needed solved my problem.
you can set env["CPPPATH"], but I hope there's an easier way...
SCons has a concept of repositories - directories to look for source and target files. These can be specified on command line.
-Y REPOSITORY, --repository=REPOSITORY, --srcdir=REPOSITORY
Search REPOSITORY for source and target files.
To get to help of SCons itself, use -H option.
no you can't, unless the developer of the scons script explicitly adds support for it.