5 ms·
Ask YC: Linux C/C++ programming workflow?
We're looking to add some C/C++ code to our repository that needs to run under Linux. Having a significant Windows background, I am trying to get a feel for a general "Linux workflow" some programmers use.
I alreasy looked at NetBeans, CodeBlock, Anjuta as far as IDEs are concerned, but strangely enough I liked vim-based code editing the most. Autotools is going to be an issue, but we'll learn it.
But how do you guys deal with help/documentation, for instance? None of the IDEs had any kind of integrated help either. Basically I am interested in well-accepted more-or-less common workflows that C/C++ coders on Linux typically follow. My distro is full of C or C++ libraries, often with doc-packages (man or info files) that I'd want to reference while coding. How do people do that? After 8 years of MSDN library it doesn't feel too good...
Thank you.
- corentin 19y agoA really cool tool is Natural Docs (at www.naturaldocs.org). It's a program like Doxygen, to generate very nice-looking HTML documentation from embedded comments. The nice thing is that comments are (as the name implies) "natural" (there are no tags that make the comments unreadable in the source code).
- st3fan 19y agoMy workflow/tools looks like this: I mostly use Emacs as my main editor. I also do debugging from Emacs. In other terminal windows I read manual pages for libc and other standard libraries, compile my code with http://a-a-p.sf.net http://a-a-p.sf.net or simply (GNU) Make. I also test my projects from the command line since most of them are daemons or command line tools anyway. Library wise I try to stick to STL and Boost for most of my C++ projects. Both are well documented in online and offline resources. I recently also added the Intel Threading Building Blocks library to my personal toolset. You did not mention anything about doing GUI work, but in that area there is a good amount of options too. I would certainly pick the one with the best community support. That will help you most in the long run I think. S.
- jey 19y agoDon't use autocrap unless for some reason you really have to. SCons is nice, you just write very simple python scripts for the build scripts. CMake is also good, it can generate native makefiles or project files for your build tools, including Unix Makefiles and Microsoft Visual Studio project files. I usually use vim, SCons, and GDB for most of my stuff. If you need a graphical debugger, try DDD. If you like IDEs, might want to try Eclipse and KDevelop. I usually use online docs in HTML format, including man pages. (So to look up how stat(2) works, I google for "stat 2 man page".) Another indispensable tool in general is GNU Screen.
- tx 19y agoThanks! I expressed my concerns regarding scons a few posts above. Another question: is there a place where Linux C programmers hang out? In case I need to ask a similar question in the future. Thank you again.
- jey 19y agoYou can try IRC: #c and #c++ on Freenode (irc.freenode.org) or EFnet (irc.efnet.org).
- Tuna-Fish 19y agoThe only ide with a major userbase in gnu-land is kdevelop, the rest of programmers generally use emacs or vim. Automake is antiquated and clumsy, use scons instead.
- corentin 19y agoSCons is good but a few things can be quite complicated, especially if you have complex builds. It took me some time to figure out how to structure things and use Repository and BuildDir correctly. edit: I do use SCons for cross-platform development on multiple architectures though, so it's probably much easier for straightforward builds under Linux.
- st3fan 19y agoScons is a good hint. I'm fairly happy with AAP but it is not really maintained anymore. Scons seems to have the same compact and to the point build files. Thanks!
- tx 19y agoI am aware of scons and cmake, but how do I distribute the code? Every single piece of Linux software I ever compiled has always been configure/make/make install. I don't mind replacing autotools, but make seems to continue being a standard way of installing from source. Am I wrong? Thank you.
- st3fan 19y agoWell you did not mention that you had to distribute it outside of your own organization. In that case it might make sense to invest in the dreadful autoconf/automake tools.
- jey 19y agoI would say you should just buck the autocrap trend and require SCons. Alternatively, you can check out "waf" which is very similar to SCons in its philosophy, but the entire application is just one python file that you can distribute with your code. I haven't tried waf yet, but I'm planning on eventually switching one of my projects to use it. http://code.google.com/p/waf/ http://code.google.com/p/waf/
- aggieben 19y agoSCons, for sure, is the way to go. I use Emacs/c-scope as my editing environment, and keep a browser and terminal (man pages) open for API reference (dinkumware.com is a good one. They have full C99 an stdc++ library documentation) Definitely make sure you're not coding something that's already been done in boost. The boost libraries (most of them) are very nice. If you're using one of the latest versions of GCC, then you can use some TR1 stuff (although I think boost has a more complete TR1 implementation (http://boost.org/doc/html/boost_tr1.html http://boost.org/doc/html/boost_tr1.html) Also, I don't know about most folks, but I also keep an IRC client open connected to #<whatever language> and a pastebin (http://pastebin.com/ http://pastebin.com/) tab open to discuss code with people when I don't have anyone else to work with.
- flashgordon 19y agoHave you looked at bjam - a make system by boost. Quite useful and a few steps closer to ant than make is. If you really need a gui - kdevelop is pretty good. If you dont mind paying for it, SlickEdit does a fine job too.