Have a C++ source I probably can't build in Code::Blocks. If I use it as an editor, would it be helpful in gaining understanding of the code? (Like Intellisense).
How does it compare to Visual Studio in this respect?
How should I go about doing it?
Can it somehow utilize gdb information (When I run it in gdb, there is a lot of information available)
It is Linux gcc/Makefile based.
The main executable is in one directory, but there are many includes, libraries etc.
If I just included all sources I would get sources for other executables (with similar code).
I expect to increase my understanding about where things are located over time.
Note 1: This is Linux, but I can easily edit on Windows. And I am trying to build under Cygwin.
Code::Blocks sounds too light weight for your tastes. Try NetBeans. It has very good hinting tools, doesn't have the infamous copy+paste bug, Its easier to navigate files, and can deal with makefiles better then C::B. Additionally it has a nice interface for debugging, and an exceptional one for performance monitoring.
I would reccomend you install a linux distro through WUBI and forgo using Windows.
I have used NetBeans, Eclipse, Visual Studio, Code::Blocks, and CodeLite. I don't normally write software under Windows anymore, but when I did CodeLite was the most elegant one I found. Debugging was a snap (mingw + GDB), all the meta information about your project is stored in an sqlite db (which I think is a great design), and it supports makefiles.
I think NetBeans would work great as well, but definitely give CodeLite a shot.
http://www.codelite.org/
Related
I am working on a project on linux and I dont understand
what really is cmake?
I have clion IDE do I explicitly need to learn about cmake?
Does Clion have cmake internally?
I am working on object detection with open detection.
CMake is sort of a wrapper around older, more complex, and often more powerful make systems. Make systems are a big topic, but in short, it is their job to notice files and do something about it (compile, link, deploy, etc)
CLion is a full GUI IDE which in turn uses CMake to do its dirty work of tracking files and what to do about them. Its primary purpose is to wrap up your compilation (via cmake) as well as give you text editors suited to the task at hand. Importantly, it also is a GUI front end for your debugging needs.
I have been looking for pros & cons of Autotools and CMake. But I would like to know opinions from people having used one (or both) of these tools for projects.
I used Autotools very basically a year ago and I know that one of the good points is that it relies on shell scripting, thus it does not need to be installed to be run and uses portable shell scripting. But it looks like it is too unix oriented, and it would not be possible to run the configure file on Windows.
I have now to choose a build system tool for an open source project that will have to be compiled for at least Linux & Windows. It is written in C++, and uses a Qt GUI front-end, the rest of it is "generic".
Thanks for you help.
Updated 16th of January 2019: Refined advice as tools evolve.
I have used autotools before for a considerable amount of time.
Currently I make intensive use of meson and cmake only when I need it.
Some personal advice:
for big teams, stick to CMake if you want to make use of the generators for XCode. If you do not need it, I would use Meson directly. Meson, as of version 0.49, also supports finding CMake configuration files (though I did not test yet how well this works). Also, Visual Studio seems to be sufficiently well-supported at this point in time, though, again, I did not try myself. The advantage of CMake is that it has Visual Studio integration.
Drop autotools. Meson covers well everything already. Their cross-compilation model is amazingly understandable. In CMake, last time I checked, everything was quite more difficult.
I have also tried scons, waf, and tup.
The most full-featured, cross-platform system, is CMake, but the DSL from meson will be easier to use for people used to python and others. Meson is starting to support VS also (a VS2015 generator) and some projects already have experimental support for it, for example gstreamer. Gstreamer is compiled in windows as well with meson. Right now there is VS2015 generator and VS2017 but I did not try myself the generators lately. As of meson 0.37.1 needed some work, but they are improving them and current version is already 0.40.
Meson
Pros:
The DSL does not get in the way at all. In fact, it is very nice and familiar, based in python.
Well-thought cross compilation support.
The objects are all strongly typed: you cannot make string substitution mistakes easily, since objects are entities such as 'depencency', 'include directory', etc.
It is very obviuos how to add a module for one of your tools.
Cross-compilation seems more straightforward to use.
Really well-thought. The designer and main writer of Meson knows what
he talks about very well when designing a build system.
Very, very fast, especially in incremental builds.
The documentation is 10 times better that what you can find in cmake. Go visit http://mesonbuild.com and you will find tutorial, howtos and a good reference. It is not perfect but it is really discoverable.
Cons:
Not as mature as CMake, though, I consider it already fully usable for C++.
Not so many modules available, though, gnome, qt and the common ones are already there.
Project generators: seems VS generator is not working that well as of now. CMake project generators are far more mature.
Has a python3 + ninja dependency.
Cmake
Pros:
Generates projects for many different IDEs. This is a very nice feature for teams.
Plays well with windows tools, unlike autotools.
Mature, almost de-facto standard.
Microsoft is working on CMake integration for Visual Studio.
Cons:
It does not follow any well known standard or guidelines.
No uninstall target.
The DSL is weird, when you start to do comparisons and such, and the strings vs list thing or escape chars, you will make many mistakes, I am pretty sure.
Cross compilation sucks.
Autotools
Pros:
Most powerful system for cross-compilation, IMHO.
The generated scripts don't need anything else than make, a shell and, if you need it to build, a compiler.
The command-line is really nice and consistent.
A standard in unix world, lots of docs.
Really powerful command-line: changing directories of installation, uninstall,
renaming binaries...
If you target unix, packaging sources with this tool is really convenient.
Cons:
It won't play well with microsoft tools. A real showstopper.
The learning curve is... well... But actually I can say that CMake was not that easy either.
The use of recursive make is pervasive in legacy projects. Automake supports non-recursive builds, but it's not a very widely used approach.
About the learning curve, there are two very good sources to learn from:
The website here
The book here
The first source will get you up and running faster. The book is a more in-depth discussion.
From Scons, waf and tup, Scons and tup are more like make. Waf is more like CMake and the autotools. I tried waf instead of cmake at first. I think it is overengineered in the sense that it has a full OOP API. The scripts didn't look short at all and it was really confusing for me the working directory stuff and related things. At the end, I found that autotools and CMake are a better choice. My favourite from these 3 build systems is tup.
Tup
Pros
Really correct.
Insanely fast. You should try it to believe it.
The scripting language relies on a very easy idea that can be understood in 10 minutes.
Cons
It does not have a full-featured config framework.
I couldn't find the way to make targets such as doc, since
they generate files I don't know of and they must be listed in the output before being generated, or at least, that's my conclusion for now. This was a really annoying limitation, if it is, since I am not sure.
All in all, the only things I am considering right now for new projects is are Cmake and Meson. When I have a chance I will try tup also, but it lacks the config framework, which means that it makes things more complex when you need all of that stuff. On the other hand, it is really fast.
I would not recommend autotools for Windows. Use CMake.
Why? Windows doesn't have a native sh.exe, and the emulation is slow. It's also very easy to get configury stuff wrong. I'm not saying it's impossible in CMake, but CMake surely abstracts more away, so you worry about less. CMake documentation can be a bit hard to read, but once it's set up, you should be fine for all toolchains ever supported by CMake. CMake also integrates testing, packaging etc...
Autotools is slow on Windows, does not work easily with MSVC, and has weird quirks with Windows (and other OSes) that are hard to debug, and hard to fix. libtool also sucks on Windows, where it often refuses to build a shared library even, if you think it should and could. Toolchain relocation issues are also prevalent with libtool, which may look at the wrong files in a user's toolchain. CMake is a lot easier in this regard. It assumes normal things about the target platform and creates generic and good build instructions.
Also, CMake has coloured output :) and nice progress percentages.
PS: I just have some experience with CMake and autotools on Windows as a user. CMake tends to work, autotools tends to bite your ear off when you're not looking, and smile at you when it fails due to some strange error...
We are currently working in a team where we use both Visual Studio and Code::Blocks, is there a way to replicate changes between those project files? So if one adds a file to the project file it will also get adjusted in the project file of the other IDE?
Please note: We want our project to work on multiple IDE's, platforms and compilers. Thus a general solution is welcome too.
I assume you're using a VCS? If so my intuition would be to write a script that syncs up your project files (based on modification date?) and run it as a checkin hook if any of the project files are changed in the commit.
http://wordaligned.org/articles/a-subversion-pre-commit-hook
Well this sounds like exactly the type of problem CMake was created to solve. There is definitely a learning curve which I blame mainly on the obtuse documentation but CMake is used in a lot of open source projects now, such as KDE, OGRE and many, many others so there are a lot of usage examples out there. There is also a basic tutorial here.
CMake uses it's own syntax (which is fairly complex though still easier than autotools in my opinion) which is used with project file generators, which supports make, visual studio, codeblocks, eclipse and possibly others. It also has a installer generator which can make NSIS installers, Mac OS X bundles and debian/red hat packages (and again, possibly others) which I find quite useful.
At home, I use CTRL+SHIFT+B or F7 or whatever key sequence initiates the build for my build tool. At work, this doesn't quite cut it.
At my first job (an internship) we used a product called Visual Build, which I have come to like very much. It's the best build tool I've ever worked with. The down side here is that it's not free.
At my latest job, I came in knowing literally nothing about Ant. Now, unfortunately, I've become deeply involved in our build processes, and cannot extricate myself. It works, yes, but after coming from Visual build, it seems like it's fighting me every step of the way. Yes, it's free, but we're not trying to be a free-software-only development company or anything.
I've never looked in to make or any other build tools, so I don't really know what else is out there.
Has anybody ever seen or had experience with Visual Build? Mostly I'm fond of a few key things:
it has a GUI
it runs arbitrary VBScript without the need of a compiled class
you can step through the build process, or start from anywhere in the middle.
Are there any free build tools that have this? Is there any way to convince people that it's worth it to move on? It's 2008. We use IDEs to develop, why not (IBEs) to build?
Edit: I'm mostly looking for an answer to my last questions; Is there a solution with a built-in GUI that I can use for free?
Not very sophisticated, but we use a set of batch files. And that works great.
We use FinalBuilder - I think it's very similar to VisualBuild, though I've not used the latter.
It does run from the command line, and you can integrate it with CC.Net if you want.
For Java projects we use Teamcity, sort of cruise control like, but you can also do a remote run, i.e. you send your changes to the server, it builds and does unit tests, if everything works ok, THEN you checkin, very nice build tool and free for up to 20 build configurations.
For our Visual Studio 2005 projects including packaging the final exes and dlls with InstallShield and putting them up on a shared server we use Final Builder, it's not free, but it is very easy to use and get started with.
We also telnet out (from FinalBuilder) to a number of other platforms (Unix/Linux/OpenVMS) and start remote builds by running makefiles there.
We do not use continous build, but there is a FinalBuilder Server which handles that and comes free with the FinalBuilder Professional license.
We are very happy with FinalBuilder, it's quite easy to get up to speed with and powerful enough to solve most problems.
CMake. Generates build file for KDevelop, Eclipse, Makefiles and Visual Studio (and XCode), and it really works. You can easily extend it with macros, although the programming capabilities are rather limited. It's easy to learn, and porting an existing application from Visual Studio to it is pretty easy. However, you are limited to C++/C and IIRC Fortran code.
KDE is also using CMake now, so it seems to scale very well (i.e. generation time for the projects/dependency checking is not too bad).
I am not sure this is exactly what you are looking for, but I LOVE CruiseControl.NET. I have it build my projects using the MSBuild task. It doesn't have a GUI exactly, but there is a web interface to view the results of your builds and a System Tray resident program which will alert you of the build status.
UppercuT. It's free.
UppercuT uses NAnt to build and it is the insanely easy to use Build Framework.
Automated Builds as easy as (1) solution name, (2) source control path, (3) company name for most projects!!!
http://code.google.com/p/uppercut/
Some good explanations here: UppercuT
Going back to the keystrokes thing for a sec, I found Hoekey which the CTO loves. I don't use it myself, but as a way of assign keystrokes to things, it's pretty good.
I know nothing of Visual Build, but from your description it sounds like it is tied to Windows and doesn't run from the command line.
If you are building Java software (I assume you are since you are using Ant), it's preferable to have a cross-platform tool. If you can run the tool from the command-line, then it is scriptable which is extremely important for automation.
Ant is also extensible and a de facto standard. Many tools that you may use (Cobertura, TestNG, etc.) provide Ant tasks so that they can easily be intergrated with your build.
I use Ant for all Java projects. Some people prefer Maven, but I'm not one of them. Ant is far from perfect (the XML syntax is a bit clunky) but it is well documented, extremely stable and pretty straightforward.
If you use a standard tool, such as Ant or Maven, you will be able to take advantage of any number of Continuous Integration products. I doubt you will find many that work with Visual Build.
Most IDEs support Ant, so they give you a GUI of sorts and your CI server will give you a web interface for doing builds.
NAnt (.NET port of Ant). Works great and is easily extensible.
For small projects I do use post-build scripts and with the support of 7z, Nsis and similar CLI tools it's doing the job perfectly for me.
TeamCity and CuriseControl works well for any projects,but here is why you would like to choose TeamCity:-
Ease of setup: During setup we found TeamCity easier to setup and use especially compared to CruiseControl. We did not need to edit XML files or massively configure individual build machines like CruiseControl.
Ease of extensibility:TeamCity stands out in its ease of extensibility too. If we find that builds are waiting in the queue too long, we can add more computers as agents. The only additional work on our end is registering the new computers with the TeamCity server and installing msbuild and subversion.
Interaction with Subversion: One can check how many and what changes were committed to subversion since the last build, who started a build etc.
I've grown very fond of scons for building C++ files. It's very straightforward and the build scripts are written in Python (which is much better than some hacked together DSL IMO).
Ant or Maven are great little build tools.
And if you want to automate the build process there are some great tools like TeamCity and Bamboo.
Personally I use Makefiles for pretty much everything because they are simple as hell. But in my work, I'm forced to use ant.
The main problem I have against ant is that XML makes it hard to read and understand, even with the correct indentation. On the other hand, the verbosity of XML can help when reading someone else's ant file, but still makes it a PITA when the file is more than a few tens of lines.
As for having a GUI to build... I've always felt that's a minus rather than a plus.
Maven is the best for me because it handles the project dependencies
As good developers we keep our code as standard compliant as possible to help in porting between platforms. But what tools are available that help us build the code in a uniform way across multiple platforms.
*nix family has make but Windows needs nmake.
I have read about SCons but never used it in anger. What is your favorite build tool, why do you find it effective and are there any limitations (i.e. platforms with bad support etc).
Cross platform IDEs as well.
cmake for c/c++ environments is good. http://www.cmake.org/
I personally use ant, rake, and maven2. I have used ant the most and find it great for several reasons:
Because it is java it works on lots of platforms (without changing any scripts)
The build files are written in XML and fairly easy to write
There are lots of 3rd party extensions available for it and it is easy to write plugins for
we do extreme cross development, and our code runs on linux, windows ce, windows 2K, nucleus and uCOS-II.
since each environment uses different 'make' methodology (out nucleus customer, for example, require us to compile via code-warrior GUI).
i used ANT combined with perl for about 2 years, but this lead the build script to total non-maintainability.
now we moved to use python, which increase the maintainability of the scripts.
bottom line, i did not find a ready-made tool, and had to build my own. maybe, when i have some time (2017 ?) i will pack my scripts and distribute them ....
If you're in the Java world, there are quite a few tools which are cross-platform. Apache Ant and Maven are both build tools which will run on any platform which has Java available for it.
Cruise Control (continuous integration tool) also works on Windows and Linux (it's written in Java as well).
I haven't had any real issues with the core tools, the only problems I've sometimes had have come from things external to the build process, i.e. publishing artifacts - this will vary between systems so I've found there's no single way of setting it up.
For C/C++ development, I've found that bakefile works well. The fairly large wxWidgets project, a cross-platform cross-platform utility and UI library, uses it for their build file generation.
Bakefile is cross-platform, cross-compiler native makefiles generator. It takes compiler-independent description of build tasks as input and generates native makefile (autoconf's Makefile.in, Visual C++ project, bcc makefile etc.).
Bakefile's task is to generate native makefiles, so that people can keep using their favorite tools. There are other cross-platform make solutions, but they either aren't native and require the user to use unfamiliar tools (Boost.Build) or they are too limited (qmake).
You can use gmake on Windows as well with cygwin/minGW or build your windows stuff on Linux.
http://cdtdoug.blogspot.com/2009/05/mingw-cross-for-linux.html
There are tools like Opus Make or MKS Toolkit that offers multiplatform and support. If you have an existing codebase of make script, could be easier migrate to one of there. I suspect you may hunt for similar tools in advertising of DDJ magazine.
We've been running a Java environment for Linux, Windows and the Mac for the last 18 months.
Maven 2 drives our builds, it's pretty easy to get things consistent here. Where M2 plugins don't dare to tread, we use small Ant scripts.
IDE-wise we're using Eclipse & IDEA - both, of course, multi-platform.
Testing - JUnit, Fitnesse, Fest - all nicely multi-platform.
Release scripts are written in Ruby. There's a bit more trouble with Windows here, but a function to convert paths as necessary generally does the trick.
TeamCity does CI. We've actually migrated this from Windows to Linux and encountered no errors at all, very nice package.
We did use GWT for a while and this did cause us large amounts of pain. Be careful if you swing that way.