I'm developing an application in C++ on Windows XP, using Eclipse as my IDE, and a Makefile-based build system (with custom tools to generate the Makefiles). In addition, I'm using LZZ, which allows me to write a single file, which then gets split into a header and an implementation file. I'm using TDM's port of GCC 4.
What tools or techniques could I use to determine exactly how much time each part of the build process takes, and why it is slow?
Of particular interest would be:
How much time does make need to figure out to parse the Makefiles, figure out the dependencies, check the timestamps, etc?
How much time does Eclipse need before and after the build?
How much time does GCC spend on parsing system and boost headers?
P.S.: This is my home project, so expensive tools are out of reach for me, but could be documented here anyway if they are particularly relevant.
Since Make and GCC are very verbose about what they're doing, a very crude way to get a high-level overview of time spent is to pipe make's output through a script that timestamps each line:
make | perl -MTime::HiRes -pe "printf '%.5f ', Time::HiRes::time()"
(I'm using ActivePerl to do this, but from what I gather, Strawberry Perl may now be the recommended Perl version for Windows.)
Reformat or process the timestamps to your liking.
To get more details about GCC in particular, use the --time-report option.
To find out how much overhead Eclipse adds, use a stopwatch to time builds from Eclipse and from the command line.
if you are using boost, most likely most of time is spent in template instantiation and subsequent optimization. You can tell GCC to report time spent, -time-report (UNIX option, might be something else on Windows GCC)
and if you are trying to speed up your compilation time, disable optimization, -O0 (last letter is number zero, first letter is capital o)
Try SparkBuild, a free gmake/nmake replacement that can generate an annotated build log with precise timing information for every job in the build. You can load that file into SparkBuild Insight to get a graphical overview of where the time goes.
See this blog for an example of how to use it.
There is a version of GNU make called remake that provides profiling information.
Related
I have a large C++ project of hundreds of files with a CMake build system. How can I use GCC's -ftime-report option but get a single summary for the full build?
I am looking to improve build times and this would be helpful to know where to focus the effort.
You would need to implement that manually by parsing the output somehow.
A good way to get a higher level overview is to use Ninja and parse the .ninja_log file:
https://github.com/ninja-build/ninja/issues/1080#issuecomment-255436851
Also see https://github.com/nico/ninjatracing. Chromium uses tools like that to keep track of build times.
Update:
-ftime-report is simply not suitable for this task as it's meant for compiler devs. Use clang and https://github.com/aras-p/ClangBuildAnalyzer for this.
gcc is far from supporting -ftime-trace: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396
My current workflow when developing Apps or programs with Java or C/C++ is as follows:
I don't use any IDE like IntelliJ, Visual Studio, ...
Using linux or OS X, I use vim as code editor. When I build with a makefile or (when in Java) gradle, I :!make and wait for the compiler and linker to create the executable, which will be run automatically.
In case of compilation errors, the output of the compiler can get very long and the lines exceed the columns of the console. So everything gets messy, and sometimes takes too much time to find out, what the first error ist (often causing all following compile errors).
My question is, what is your workflow as a C++ developer? For example is there a way, to generate a nicely formatted local html file, that you can view / update in your browser window. Or other ideas?
Yes, I know. I could use Xcode or any other IDE. But I just don't want.
Compiling in vim with :!make instead of :make doesn't make any sense -- it's even one of the early features of vim. The former will expect us to have good eyes. The latter will display compilation errors into the quickfix window, which we can navigate. In other words, no need to use an auxiliary log file: we can navigate compilation errors even in (a coupled of) editors that run into a console.
I did expand on a related topic in https://stackoverflow.com/a/35702919/15934.
Regarding compilation, there are a few plugins that permits to compile in background. I've added this facility in build-tool-wrapper lately (it requires vim 7.4-1980 -- and it's still in a development branch at this time). This plugin also permits me to easily filter errors in the standard library with the venerable STLfilt, and to manage several build configurations (each in a separate directory).
We have a not very complicated but big (i.e. lots of files) Visual Studio C++ Win32 Console written in C++0x standard in VS2010.
It does not use any non standard code or anything (Hopefully!).
I now wanna port it to Linux.
Which way is the quickest way to do it?
autoconf?
old-fashioned make file?
any other solution?
I would use regular make but keep it simple with default rules as much as possible. Add in dependencies as you go along.
EDIT: As in interim step, build it with mingw so that you can avoid the whole API porting issue until you have a working build in your new build mechanism.
If your console app calls win32 API functions then you have a choice between modifying all the source where it is used or writing a module that implements those functions.
In prior porting efforts of this type I tried it both ways and the latter was easier. I ended up writing only about 18 to 20 shim functions.
It was successful enough that I ended up writing an OS abstraction layer that was used on many projects that simply let me compile on Windows native, cygwin, Linux, VxWorks, etc. with trivial changes to one or two files.
(p.s. Any interest in an open source version of a C++ based OS abstraction layer? I was thinking of releasing an unencumbered version of it to the world if there's sufficient interest. It's mostly useful where BOOST is too heavy -- i.e. embedded projects.)
Most probably you don't need autoconf (and I suggest you don't touch it, unless you love pain), because you are not trying to be portable to a dozen of Unix flavours.
Roll your Makefiles manually. It shouldn't be too difficult if you have a set of shared rules and have minimal Makefiles that just specify source files and compile options.
Use GCC 4.5 as it supports more C++0x features.
You can export a make file from Visual Studio.
Update: Actually you can't anymore, unless you have VC6 lying around
STAY AWAY FROM AUTO* and configure. These are horrible IMHO.
If you can somehow get a VS 8 or 9 vcproj/sln, you can use this. I have not used it, so I can't give any advice.
If you're up to manual conversion, I would suggest something like CMake, as it's pretty easy to get ready fast enough, even for large projects.
If the project has a simple layout, you could have success using Qt 4's qmake like this:
qmake -project
It will output a qmake .pro file, which can be converted into a makefile on many platforms (using qmake). This should work okay, but not perfectly. Alternatively, you can install the Qt plugin for VS, and let it generate the pro file from an existing VS project. It will make your build system depend on Qt4's qmake, which is probably not what you want.
There are of course other things like cmake, but they will all require manual intervention.
The fastest way to do it?
g++ *.cpp -o myapp
Seriously, depending on your needs, even generating a makefile might be overkill. If you're just interested in a quick and dirty "let's see if we can get a working program on Linux", just throw your code files at g++ and see what happens.
we work under Linux/Eclipse/C++ using Eclipse's "native" C++ projects (.cproject). the system comprises from several C++ projects all kept under svn version control, using integrated subclipse plugin.
we want to have a script that would checkout, compile and package the system, without us needing to drive this process manually from eclipse, as we do now.
I see that there are generated makefile and support files (sources.mk, subdir.mk etc.), scattered around, which are not under version control (probably the subclipse plugin is "clever" enough to exclude them). I guess I can put them under svn and use in the script we need.
however, this feels shaky. have anybody tried it? Are there any issues to expect? Are there recommended ways to achieve what we need?
N.B. I don't believe that an idea of adopting another build system will be accepted nicely, unless it's SUPER-smooth. We are a small company of 4 developers running full-steam ahead, and any additional overhead or learning curve will not appreciated :)
thanks a lot in advance!
I would not recommend putting things that are generated in an external tool into version control. My favorite phrase for this tactic is "version the recipe, not the cake". Instead, you should use a third party tool like your script to manipulate Eclipse appropriately to generate these files from your sources, and then compile them. This avoids the risk of having one of these automatically generated files be out of sync with your root sources.
I'm not sure what your threshold for "super-smooth" is, but you might want to take a look at Maven2, which has a plugin for Eclipse projects to do just this.
I know that this is a big problem (I had exactly the same; in addition: maintaining a build-workspace in svn is a real pain!)
Problems I see:
You will get into problems as soon as somebody adds or changes project settings files but doesn't trigger a new build for all possible platforms! (makefiles aren't updated).
There is no overall make file so you can not easily use the build order of your projects that Eclipse had calculated
BTW: I wrote an Eclipse plugin that builds up a workspace from a given (textual) list of projects and then triggers the build. That's possible but also not an easy task.
Unfortunately I can't post the plugin somewhere because I wrote it for my former employer...
I'am aware there has been a generic question about a "best IDE in C++" but I would like to stress I'm a new to C++ and programming in general. This means I have the needs of a student:
relatively easy and unbloated working environment
things just work, focus on the code
color coding to show the different language features (comments, etc)
not too unfriendly (not a simple editor, something to handle projects from start to finish)
cross-platform so not to be bound with specific system practices
I think the above are relatively reasonable demands for an educational IDE, perhaps excluding the last as such universal tool might not exist. Any ideas?
It depends on which world are you coming from to learn C++.
Do you have previous Java experience? - Use Eclipse CDT.
Have used .NET previously? - Go with Visual Studio C++ Express Edition (and then throw it away if you really need multiplatform IDE, not just code).
Are you an Unix guy? Use just a syntax-highlighting editor + Makefile. When you want to learn basics of the C++, the project should not be complicated and it is well invested time to learn how the C++ compiler is called with preprocessor options, etc.
Code::Blocks is free and really easy to install and use. I always recommend it to my students.
I've heard good things about Code::Blocks. Might be a bit complex, but you can close any unneeded panes, and it's cross-platform.
I would recommend Komodo Edit.
It functions as a great text editor that I've used on Ubuntu, Windows(XP/7) and OSX. It's big brother is a full blown IDE but KE still allows for projects and some great extensions. It's also free and open source. I found it easy to get started quickly with it and as your skills grow, it has the ability to keep up.
Edit to add a link to ActiveState's community site for Komodo Extensions. If you decide to try out KE, I'd suggest the RemoteDrive Tree (ssh,ftp,scp remote editing) and Source Tree as a start.
If you are using both windows and linux (as your comment indicates), I'd recommend Qt Creator. Qt is cross platform so your apps will work on linux, windows, and mac. Qt has excellent documentation, too, so it's very newbie friendly. Signals and Slots take a bit of getting used to, but IMO it's worth it.
Until the last point I would have said Microsoft Visual C++ Express Edition, which is free and fits your first 4 criteria. Cross platform you'd be looking at something like emacs or vim, neither of which are particularly friendly. On Windows I actually use Notepad++ for small C++ programs as it has good syntax highlighting and a (limited) intellisense.
I'd recommend Eclipse CDT as it does good code completion and it builds code on the fly, so you can see your errors immediately which is very good for a language studying.
Assuming Linux/Unix like system ...
I've found out that it's much easier and beneficial to go the other way round. Try using 'simple' editor like vim and for C++ just Makefiles to compile using gcc and linker.
I've started using that at uni and 5> years and couple of companies later it's still the easiest and most flexible option because you have quick access to all settings in one simple file.
Even when you switch to IDE later on you will know what to look for if things don't work because you will know the basics for example what are the steps to go from source file to object file and link to binary executable, how to handle libraries and so on. These things change between IDE's and are often complicated to trace and modify.
You can start with simple makefile and keep improving it over years. It's easy to copy it to your project directory and update file names - for C++ the compilation process will be fairly standard between projects.
I highly encourage you to consider this option. I've learned a lot doing it that way and you have a backup plan when you IDE just wouldn't work.
I keep one generic Makefile that compiles main.cpp into executable. To compile something quickly I just copy it into directory and make.
My current workflow is to open all files in project directory (flat file system) with vim (vim *.cpp *.hpp), edit, compile with :mak (or :mak -C .. debug) from within vim to invoke the Makefile stored in relevant directory, after compiling it'll jump to first warning/error, use :cn to go over errors, fix what's needed, open errors in separate window with :cope (close with :clo or unload file with :bd, jump between split windows with ctrl-w ctrl-w or ctrl-ww - hold ctrl and press w twice) ...
Vim has syntax highlighting millions of other features, I'm using tags (or ctags) to navigate code from within vim and so on.
Personally, it's my opinion that all C++ IDEs suck. When I write C or C++, I tend to use some sort of powerful programmer's text editor along with command line compilation. If I'm just messing around and have a couple source files, I'll just invoke gcc -g -o myprog *.c on the command line myself. If I have a more involved project, I'll just write a simple makefile. You could also look into gmakemake if you don't want to bother learning makefile syntax just to compile your programs.
On the Mac side, I have always been a fan of both BBEdit and TextMate, but much more so of the latter, especially given its lesser price tag and more modern feel. Both have project organization features.
On Windows, I'd stick with either e (which is basically a port of TextMate to Windows) or Notepad++. The downside of Notepad++ is that it doesn't have any project organization features, whereas e does. You could also look at SciTE, but like Notepad++, it has no project org features.
As for Linux, I'm personally unsure. I'd stick with other people's answers covering that platform for recommendations there.