Related
I'm a windows developer and I need to use Code::Blocks
to develope multiplataform C++ GUI applications.
After installing Code::Blocks and wxWidgets in my first try to do a simple "Hello World" application, the IDE show me a box with $(#wx)
What is the $(#wx) ?
Googling for tutorials I see this
What is the -g ?
Finally the following error message appear:
For 3 days I'm trying over and over again without success !
I even try wxPack. Nothing works !
With VC++, C++Builder and even wxDev-C++ this is straightforward
Only Code::Blocks is so difficult !
Googling, I find many people with the same error, but the advices they get didn't work for me !
Can someone tell me step by step what I must do?
Thank you.
Your frustration comes, as usually does, from your ignorance. If your are required to learn about C::B, well, that's life. Don't waste time on getting so angry, life is short.
CodeBlocks are not tied to a compiler. You can use VC++, MinGW, TDM-GCC, GCC, etc. Thus, you must tell C::B the compiler to use. You may use different compilers for different "targets" (see below).
C::B is not tied to any library either. If you want to use wxWidgets you must tell C::B about the needed files and where to find them.
It's very common that people who use C::B use MinGW as the compiler. That's why when you first install C::B it searches for MinGW and, if found, set it as the default compiler. You can set your own preference in Settings->Compiler. Same goes for the debugger, usually GDB.
As a side note, be aware that MinGW is ONLY 32 bits. There's a different compiler (MinGW 64). TDM-GCC offers both compilers (and their GDB versions) at once, I recommend installing 32/64 versions in different folders and setting them in C::B as different compilers. For Linux, the "mother" GCC is the de-facto standard.
When you build your app you must define a target. This is nothing else but a way of telling things like "I want a 32 bit library" or "I want a 64 executable". In your required project you may set several targets. Select the desired one before compiling (combobox in the main tool bar).
While developing it's very advisable to set a target as a "debug". This means you want to use the debugger. This requires to use "debug symbols". With GCC (or one of its "children", MinGW...) you acomplish it but adding -g as a flag to the compiler.
Now you understand that probably you set not only one, but several targets like "release 64 exe", "debug 32 exe" etc. Right?
wxWidgets joins in scene
Despite C::B is made with wxWidgets, it doesn't ship with it. Download the version you like from wxWidgets site. While some binaries are offered, if you use some other compiler or some other parameters then you need to compile wxWidgets on your own. See the docs/msw/install.txt and learn about the different configurations (release, debug, static/dynamic lib, etc). Your "target" must match the wxWidgets configuration, so better build several versions, same as your targets. And don't forget to use the same parameters for your app target as you used to each wxWidgets target. You can do this at Project->Build options.
As with any compiler you must tell where to find the libraries and the headers. And the libraries you want to use. The Windows libraries (kernel32, user32, etc, they are a lot, ask in another thread) and the wxWidgets libraries.
When you update your app perhaps you use a newer wxWidgets version, but also want to support an older version with other wxWidgets version. You have several folders. For your project you should update all directories. Can this be done shortly? Yes. in C::B you can define variables(e.g. $wx31dir) and use them like $(wx31dir)/include. Redefining the var saves you a lot of typing.
You can use a global var $(#wx31dir) or several, project fitted vars. Your decision.
Finally, C::B offers a project template for a wxWidgets app. It will ask you some locations (wx dirs) and vars. If you don't understand well what it does, better don't use it and set everything on your own. First time is hard, I know. Go ahead and you'll get it if you pay attention to needed steps.
Have you read the CodeBlocks manual?
Since you having hard time using C::B, I suggest you switch to CodeLite which I find simpler to start with than C::B (My experience). Everything you need is documented on CodeLite Wiki. Creating project is well documented with screenshots but before you compile, open environment variables (Settings->Environment Variables) and add line WXWIN=/path/to/your/wxwidgets/installation and compile as it is explained there.
Ouch....
You do not need to interact with code::blocks at all to use wxwidgets.
You can simple download wx header and binary package (depends of your compiler), place it on directory and import (with #include) it in your source code.
I do not see what is relevant to C::B? You can use any library without compiling and setting any variable in your editor (IDE) - but then you lack of lot of feuters.
I hope that
Using wxWidgets Pre Built Binary in CodeBlocks at wxWidgets wiki
and
Using wxWidgets (MSW) 3.0 Binary with Code::Blocks Scripted Wizard
would be best and useful answer for your question.
Even I want to use wheel for my convenience every day, but I don't want to invent the wheel every day again and again.
Even that your question is about wxWidgets and Code::Blocks for MS Windows, and that the answer links are of the wxWidgets and Code::Blocks own,
For recommended stability, I include the full screenshot of this document of wxWidgets own wiki
and
this of Code::Blocks own wiki
I don't understand, why do we need cmake to build libraries ? I am sorry if my question is stupid, but i need to use some libraries on Widnows, and what ever library i choose i need to build it and/or compile it with cmake.. What is it for ? Why cant i just #include "path" the things that i need into my project, and than it can be compiled/built at the same time as my project ?
And also, sometimes i needed to install Ruby, Perl, Python all of them some specific version so cmake can build libraries... Why do i need those programs, and will i need them only to build library or later in my project too ? (concrete can i uninstall those programs after building libraries ?)
Building things in c++ on different platforms is a mess currently.
There are several different build system out there and there is no standard way to do this. Just providing a visual studio solution wont help compilation on linux or mac.
If you add a makefile for linux or mac you need to repeat configurations between the solution and the makefiles. Which can result in a lot of maintenance overhead. Also makefiles are not really a good build tool compared to the new ones out there.
That you have only CMake libraries is mostly a coincidence. CMake is though a popular choice currently.
There are several solutions out there to unify builds. CMake is a build tool in a special way. It can create makefiles and build them but you can also tell cmake to create a visual studio solution if you like.
The same goes with external programs. They are the choice of the maintainer of the library you use and there are no standards for things like code generation.
While CMake may not be "the" solution (although the upcoming visual studio 2015 is integrating cmake support) but the trend for those build system which are cross-platform is going more and more in this direction.
To your question why you cannot only include the header:
Few libraries are header only and need to be compiled. Either you can get precompiled libs/dlls and just include the header + add the linker path. This is easier in linux because you can have -dev packages which just install a prebuild library and it's header via the package manager. Windows has no such thing natively.
Or you have to build it yourself with whatever buildtool the library uses.
The short answer is that you don't, but it would probably be difficult to build the project without it.
CMake does not build code, but is instead a build file generator. It was developed by KitWare (during the ITK project around 2000) to make building code across multiple platforms "simpler". It's not an easy language to use (which Kitware openly admits), but it unifies several things that Windows, Mac, and Linux do differently when building code.
On Linux, autoconf is typically used to make build files, which are then compiled by gcc/g++ (and/or clang)
On Windows, you would typically use the Visual Studio IDE and create what they call a "Solution" that is then compiled by msvc (the Microsoft Visual C++ compiler)
On Mac, I admit I am not familiar with the compiler used, but I believe it is something to do with XCode
CMake lets you write a single script you can use to build on multiple machines and specify different options for each.
Like C++, CMake has been divided between traditional/old-style CMake (version < 3.x) and modern CMake (version >= 3.0). Use modern CMake. The following are excellent tutorials:
Effective CMake, by Daniel Pfeifer, C++Now 2017*
Modern CMake Patterns, by Matheiu Ropert, CppCon 2017
Better CMake
CMake Tutorial
*Awarded the most useful talk at the C++Now 2017 Conference
Watch these in the order listed. You will learn what Modern CMake looks like (and old-style CMake) and gain understanding of how
CMake helps you specify build order and dependencies, and
Modern CMake helps prevent creating cyclic dependencies and common bugs while scaling to larger projects.
Additionally, the last video introduces package managers for C++ (useful when using external libraries, like Boost, where you would use the CMake find_package() command), of which the two most common are:
vcpkg, and
Conan
In general,
Think of targets as objects
a. There are two kinds, executables and libraries, which are "constructed" with
add_executable(myexe ...) # Creates an executable target "myexe"
add_library(mylib ...) # Creates a library target "mylib"
Each target has properties, which are variables for the target. However, they are specified with underscores, not dots, and (often) use capital letters
myexe_FOO_PROPERTY # Foo property for myexe target
Functions in CMake can also set some properties on target "objects" (under the hood) when run
target_compile_definitions()/features()/options()
target_sources()
target_include_directories()
target_link_libraries()
CMake is a command language, similar shell scripting, but there's no nesting or piping of commands. Instead
a. Each command (function) is on its own line and does one thing
b. The argument(s) to all commands (functions) are strings
c. Unless the name of a target is explicitly passed to the function, the command applies to the target that was last created
add_executable(myexe ...) # Create exe target
target_compile_definitions(...) # Applies to "myexe"
target_include_directories(...) # Applies to "myexe"
# ...etc.
add_library(mylib ...) # Create lib target
target_sources(...) # Applies to "mylib"
# ...etc.
d. Commands are executed in order, top-to-bottom, (NOTE: if a target needs another target, you must create the target first)
The scope of execution is the currently active CMakeLists.txt file. Additional files can be run (added to the scope) using the add_subdirectory() command
a. This operates much like the shell exec command; the current CMake environment (targets and properties, except PRIVATE properties) are "copied" over into a new scope ("shell"), where additional work is done.
b. However, the "environment" is not the shell environment (CMake target properties are not passed to the shell as environment variables like $PATH). Instead, the CMake language maintains all targets and properties in the top-level global scope CACHE
PRIVATE properties get used by the current module. INTERFACE properties get passed to subdirectory modules. PUBLIC is for the current module and submodules (the property is appropriate for the current module and applies to/should be used by modules that link against it).
target_link_libraries is for direct module dependencies, but it also resolves all transitive dependencies. This means when you link to a library, you gets all the PUBLIC properties of the parent modules as well.
a. If you want to link to a library that has a direct path, you can use target_link_libraries, and
b. if you want to link to a module with a project and take its interface, you also use target_link_libraries
You run CMake on CMakeLists.txt files to generate the build files you want for your system (ninja, Visual Studio solution, Linux make, etc.) and the run those to compile and link the code.
I'd like to use open source library on Windows. (ex:Aquila, following http://aquila-dsp.org/articles/iteration-over-wave-file-data-revisited/) But I can't understand anything about "Build System"... Everyone just say like, "Unzip the tar, do configure, make, make file" at Linux, but I want to use them for Windows. There are some several questions.
i) Why do I have to "Install" for just source code? Why can't I use these header files by copying them to the working directory and throw #include ".\aquila\global.h" ??
ii) What are Configuration and Make/Make Install? I can't understand them. I just know that configuration open source with Windows need "CMake", and it is configuration tool... But what it actually does??
iii) Though I've done : cmake, mingw32-make, mingw32-make install... My compiler said "undefined references to ...". What this means and what should I do with them?
You don't need to install for sources. You do need to install for the libraries that get built from that source code and that your code is going to use.
configure is the standard name for the script that does build configuration for the software about to be built. The usual way it is run (and how you will see it mentioned) is ./configure.
make is a build management tool (as the tag here on SO will tell you). One of the most common mechanisms for building code on linux (etc.) is to use the autotools suite which uses the aforementioned configure script to generate build configuration information for use by generated makefiles which make then uses to build the software. make is also the way to run the default build target defined in a makefile (which is often the all target and which usually builds the appropriate library/binary/etc.).
make install is a specific, secondary, invocation of the make tool on the install target which (generally) installs the (in this case previously) built code into an appropriate location (in the autotools/configure universe the default location is generally under /usr/local).
cmake is, again as the SO tag says, a build system that generates configuration files for other build tools (make, VS, etc.). This allows the developers to create the build configuration once and build on multiple platforms/etc. (at least in theory).
If running cmake worked correctly then it should have generated the correct information for whatever target system you told it to use (make or VS or whatever). Assuming that was make that should have allowed mingw32-make to build the software correctly (assuming additionally that mingw32-make is not a distinct cmake target than make). If that is not working correctly then something is still missing from your system (and cmake probably should have caught that).
But to give any more detail you will need to give more detail about what errors you are actually getting and from what command.
(Oh, and on Windows, and especially if you plan on building your software with VS (or some other non-mingw32-make tool) the chances of you needing to run mingw32-make install are incredibly small).
For Windows use cmake or latest ninja.
The process is not simple or straight, but achievable. You need to write CMake configuration.
Building process is not simple and straight, that's why there exists language like Java(that's another thing though)
Rely on CMake build the library, and you will get the Open-Source library for Windows.
You can distribute this as library for Windows systems, distribute and integrate with your own software, include the Open Source library, in either cases, you would have to build it for Windows.
Writing CMake helps, it would be helpful to build for other platforms as well.
Now Question comes: Is there any other way except CMake for Windows Build
Would you love the flavor of writing directly Assembly?
If obviously answer is no, you would have to write CMake and generate sln for MSVC and other compilers.
Just fix some of the errors comes, read the FAQ, Documentation before building an Open Source library. And fix the errors as they lurk through.
It is like handling burning iron, but it pays if you're working on something meaningful. Most of the server libraries are Open Source(e.g. age old Apache httpd). So, think before what you're doing.
There are also not many useful Open Source libraries which you could use in your project, but it's the way to Use the Open Source libraries.
I am in need to create a makefile for visual studio. however the documentation for this on Microsoft websites is very gently speaking: lousy. Googling doesn't help either. Could somebody paste a link or simple tutorial on how to create such makefile (for example compiling one program from two cpp files). Also mentioning if include files like in GNU are possible to use (and how to import them in makefile). Or how can i echo something in makefile.
I have seen this but is of not much help.
Try using CMake. It's a cross platform build system. I have used it to generate project and solution files for VS 2010, however there is NMake generator also.
This video should get you started - http://www.youtube.com/watch?v=w9sKd8f0kFo.
I'm developing cross-platform c++ project. The original idea is to work with msvc2010 and later compile for other systems with the help of CMake and Hudson.
It doesn't seem to be convenient manually change CMake files after changes in studio settings.
So, what’s the easiest way: to write parser for vcxproj and vcxproj.filters, or there is another good solution?
It might be useful, from time to time, to do this type of conversion, say for porting. On my travels I've found the following, in no particular order:
Specifically for VS to CMake/GYP:
vcproj2cmake
vcxproj2cmake (not a typo!)
gypify.py is a .sln/solution-reading Gyp file generator. Gyp is a Cmake alternative, currently being used by the Chromium project (base for Google's Chrome browser). Gyp will output Makefile, Visual Studio or XCode build files (see Gyp's '-f [make|scons|msvc|xcode]' switch). This Python script is quite promising, I'm hoping to modify it soon to correctly specify header-containing folders for gcc's '-I' include parameter.
Other Cmake/Make-related conversion tools:
Make It So Converts Visual Studio solutions to Linux gcc makefiles
sln2mak C# project
sln2mak Perl script
GUCEF Project includes the ProjectGenerator tool, for Cmake
gencmake (ruby) – KDE Project
'pbtomake' says it can convert XCode xcodeproj/pbproj files to Makefiles (maybe outdated)
Cheers
Rich
You're coming at it backwards -- set up all your CMakeLists.txt and then generate the MSVC project from it.
It shouldn't be hard or time-consuming. Basically you just need to say which directories to look into, declare your include paths, collect your *.cpps for each library with a glob expression, and declare your dependencies.
If you have to set up anything else, then your project probably isn't very portable :-/
The best tool for this purprose is cmake-converter