code::blocks, libxml2 / libxml/parser.h: No such file or directory - wxwidgets

Hello
I'm trying to write some tool using code::blocks, wxWidgets and libxml2 on Windows platform.
Things I've done:
copied libxml2.a, libxml2.dll.a and
other libs to MinGW lib/ folder
Wrote some headers like this in my
source file:
#include <libxml/xmlmemory.h>
#include <libxml/parser.h>
Added -lxml2 to linker
And now, when I'm trying to build this project I'm getting this error:
error: libxml/xmlmemory.h: No such file or directory
Anyone here experienced this error?
I believe that I misconfigured something but don't really know what.
Thanks for your ideas.

In general, it's better to not move things into the mingw directories, but to leave them in their own directories, and add search paths to the project properties so it knows where to look for them.
If you go into your project properties in Code::Blocks, hit the Project build options button, then inside the Linker Settings tab, add the two libraries you're linking against. Then In the Search directories tab, add the /include to compiler search locations, and optionally, add the /lib directory to Linker locations (This isn't necessary if you gave the full path to the .a in the linker settings.

Ok, I found the solution!
<libxml2/libxml/parser.h>
works perfectly

Related

How to manipulate headers linking with CMake and CMakeLists.txt

Is there a way to create an alias for #included resources within one of the directives of CMakeLists.txt?
I am looking for a way to define something in the CMakeLists.txt so any occurrence of global resource like
#include <some/global/dependency/file.h>
will be aliased to the right resource, so CMake will also look for it in the following locations
#include "../file/is/here/file.h"
#include "file.h"
#include <alias.h>
Why?
I am working on a very complex project with containerized build system. Means, lot of manual work should be done to make the project play well in any IDE. Actually, there are lot of sub projects within the main project that being individually compiled with lot of dedicate configurations.
I am using CLion as my IDE. CLion support CMake out of the box, but my project is not using cmake :) I created custom CMakeLists.txt file by simply including lot of folders (with header files) by using include_directories() directive, and for now it works very well. It able to recognize symbols/navigation/macros generation and build a nice index of the included files.
But I have this problem where, in some files CLion not able to recognize the file path because the #include refers to global (prebuilt / containerized) path/file which does not exist on my real file system, but generally, any such resource exist in the project under different path. So I wonder is there a way to just instruct CMake to do the following:
IF asked to #include something from XXX path
THEN first look for it under YYY path or ZZZ path etc'...
if the resource not found in step 2 above, look for it under XXX path
I will appreciate if you can help me to improve the question and title by editing it with better terminology etc'...
CMake by itself doesn't provide a compiler, it is even not a build tool. So, if a compiler cannot replace include directories "on fly", CMake cannot do so.
If you are allowed to copy headers - copy them in proper location, so include_directories() will work.
If you are allowed to copy and modify sources, you may copy them into the new location and run scanner on them, which modifies #include directives.
Otherwise you are out of luck.

issue when building module using cmake

i am trying to build box2D using cmake. When i click configure (and selecting my version of visual studio) cmake starts working but it finnishes with the error message:
You have called ADD_LIBRARY for library glfw without any source files.
This typically indicates a problem with your CMakeLists.txt file
Configuring done
What is the issue and how can i solve it? Where is the CMakeLists.txt located and how can i edit it to build without errors?
It is probably an error in this library. Try another version or post a bug.
It means that according to this file, a library should be created without source files (an empty library), which is probably bug.
CMakeLists.txt is located in every cmake source directory, make sure you're choosing the right directory.

CMake for Code::Blocks -- how to NOT get a Makefile

Here is my setup:
Windows 7 x64, MingW, Msys, CMake, Freescale Kinetis SDK, Code::Blocks
I'm trying to get the project settings established by CMake into a proper Code::Blocks project. When I modify the provided build_debug.bat file with -G "CodeBlocks - Unix Makefiles", it indeed produces a .cbp file, as well as the normal Makefile (and it builds the project). However when I open this .cbp file in Code::Blocks, it basically just points to the Makefile, and building the project just runs make on the Makefile.
If I deselect "This is a custom Makefile" from Project Options, and add a source file to the project tree like a normal IDE, it doesn't get built correctly, ie the include files, libraries, linker stuff, compile options, etc., are not imported into the project itself. It seems the project is basically just a holder for the Makefile, so there is not much benefit to this as an IDE.
Of course if I add the source file to the original CMakeLists.txt which is part of the distribution, and rerun cmake (via the build_debug.bat file), then it works fine.
So is there any way to get a "real" IDE configuration out of CMake? I'm guessing the answer is No, since a "real" IDE configuration is a static thing, and a Makefile is a general (Turing complete) program, so there is no way in general to create this automatically, although I suspect for 99% of cases you're just specifying include directories, lib files, and compiler options, so no general programmability is truly needed.
I can probably try to figure out where the deeply obscured gcc calls are getting their include files from, what libs are being linked in, and what compile options are being used, and add all that stuff manually into a native Code::Blocks project, but this seems to defeat the purpose of having this already done for me by the package providers, and gets very tedious when building for a different CPU or development board.
Thanks
"Real configuration" is a CMakeLists.txt, and you need to modify CMakeLists when you editing project configuration. Both makefiles and IDE settings generated by CMake are temporary and you should not edit them.
Some IDEs are able to manage project configuration directly in the CMakeLists.txt

Trouble Linking libsndfile in Visual Studio 2010 Express

I've been attempting to use libsndfile (it is the windows 64 bit version) for the first time, and have encountered a problem while trying to link it. Whenever I try to compile the program, I get this error:
error LNK2019: unresolved external symbol _sf_close referenced in function _main
This is the process I've done so far to attempt to link it to the program.
In project properties I have gone to Config. Prop.-> VC++ Directories, and added the path to the header files to the include directories tab, and the path to the .lib files to library directories tab.
In C/C++-> General-> Additional Include Directories, I have added the path to the header files.
In Linker->Input->Additional Dependencies I have added the path to the .lib file, which for me is C:\Program Files\Mega-Nerd\libsndfile\lib\libsndfile-1.lib
I've added #include "sndfile.h" to the .cpp file but for some reason it doesn't seem to have access to the functions in the dll. I don't really know a lot about linking, and what I've done is just what I've been able to piece together from scouring the internet, so I'm not really sure on what I'm doing wrong or right. Any help is greatly appreciated.
You are probably compiling a 32 bit project in Visual Studio, and trying to link it with a 64 bit library. It won't work... download the 32 bit version of the windows binary of libsndfile and use it to link to your executable. Another option is to create a 64 bit project, but I think the first option is (slightly) easier.

Having trouble getting CMake to work with third party libraries

I'm trying to make a small game using both SFML and Box2D. I have the following directory structure:
/
src/
game/ # my code
thirdparty/ # other libraries' code
box2d/
sfml/
bin/
etc...
I'm trying to set it up so that I can run make and have box2d or sfml compile as well if they need, since I might make some changes to the libraries.
I've tried putting this in my CMkaeLists.txt:
find_package(Box2D)
find_package(sfml-window)
find_package(sfml-graphics)
find_package(sfml-system)
as well as other things, but I keep getting errors and I'm not sure how to get around them. for example:
CMake Error at CMakeLists.txt:20 (find_package):
Could not find module Findsfml-window.cmake or a configuration file for
package sfml-window.
Adjust CMAKE_MODULE_PATH to find Findsfml-window.cmake or set
sfml-window_DIR to the directory containing a CMake configuration file for
sfml-window. The file will have one of the following names:
sfml-windowConfig.cmake
sfml-window-config.cmake
But I can't find any of the files it lists there.
The find_pacakge command is for finding packages that are defined in for cmake as modules or configurations. There is probably not a cmake module or config defined for these libraries. So, if you want to use the find package command to find these libraries then you will need to create a cmake module that knows how to find them. Given your stated requirements I would not think that this is easiest way to do it.
If you are statically linking you libraries then set up a custom target to invoke make on each of the libraries. Add the include directories to your include path. Use find_library command to find the libraries.
If you intend to dynamically link your libraries then create a custom target to build and install your libraries and you should be good as long as you install them in one of the normal places.
Have a gander here:
http://www.itk.org/Wiki/CMake:How_To_Find_Libraries Writing find modules
Take a look at the "Writing find modules" section. Be sure to read the document all the way through.
If you want to make redistributable and portable cmake projects, I think this is the right direction for you to go.