Development environment

[Snurg]

drhowarddrfine
Why I do not like to use pure gdb: http://www.catb.org/esr/writings/unix-koans/oldhand.html

 

[drhowarddrfine]

Snurg You are misinterpreting what he's saying. He's not saying don't use Unix tools that have been around a long time.

 

[Eric A. Borisch]

I am sorry guys, I have used gdb numerous times, but having a GUI (I am talking about an X-window desktop environment - xfce, kde, gnome, you name it- with windows etc, and I do not consider dozens of tiled terminals as a GUI) and being able to see locals, your watched variables, stack etc. makes life easier....

You mean like this: https://camo.githubusercontent.com/...92e696d6775722e636f6d2f486759564d444e2e706e67

I can get code completion, syntax analysis, etc. in vim, and a nice terminal-“gui” debugger in lldb, all in packages that can run on systems that don’t have an X install, like my router box.

 

[Maelstorm]

I dunno. I pretty much just use VI for my coding needs.

 

[ahrkahrg]

I tried installing devel/codeblocks but after displaying its logo it just core dumped.

Any suggestions on what to look for?

I ran pkg install codeblocks and all was working fine. So far the easiest IDE to work with for simple console applications.

 

[ahrkahrg]

If you do not want to install or you don't need a glitzy GUI styled IDE or Emacs (actually a pretty friendly environment written by Richard Stallman), you can use vim or you can simply use the built-in debugging UI of GDB, by executing gdb with the “-tui” option:

View attachment 4253

Here it's shown debugging a simple OS kernel from Visopsys.org. The advantage of using the bare gdb debugger is that it will teach you the basics of debugging, without a fancy front-end GUI that may shield details that could help deeper understanding. Emacs works via direct interaction with the debugger as well. Maybe that combo could be a sort of intermediate step to get you going, since it's a very simple command line startup. Instant gratification, and not much prior knowledge needed.

I kinda like emacs for small projects (grin). Here's what tha man has to say about it:

I believe the purpose is to have an IDE to be able to create .so and .lib and manage the projects easily with a specific compiler.
I personally find the debugger a tool allowing easy/lazy programming. I believe a true developer should be able to point out a bug or issue using printf on the console. This night be difficult for GUI application but a log file can do the trick. Working without a GBD forces you to think and analyze the code instead of test and try.

 

[ahrkahrg]

(Quite an old post but...)
If you are just starting out with development, then codeblocks is great. However if you are looking at honing your skills professionally, then IDEs are simply too inflexible and the better developers that I have worked with avoid them.

Perhaps try the following instead:

1) clang (C Compiler) or clang++ (C++ compiler)
2) gedit (simple text editor) or vim, emacs (more advanced text editors)
3) gdb, (Debugger so you can set breakpoints, step through the program)

One of the main reasons why IDEs are limited is because they don't well integrate the following important tools:

cmake (cross platform build system. Visual Studio .sln or code::blocks .proj files are not often used by other developers)
valgrind (runtime memory checker)
splint (static analysis)
doxygen (generating callgraphs / reverse callgraphs is very important for large teams)
jenkins / hudson (Build systems work with the command line. They often have very limited support for IDEs)
git / svn (version control support is always lacking in IDEs because the proj files or settings files do not merge well).

I agree with your statement. I was impressed at clang vs gcc and compiling once my project with clang convinced me it is a far superior providing useful feedback tot he developer.
Can you recommend a simple text editor with simple and easy configurable syntax highlights?

 

[ahrkahrg]

This is one thing I am missing as well....CodeBlock was "okay" but the port has been broken for a while...
I may give a go to editors/codelite, seems like the best bid I (we) have... I have never been a java/eclipse fan to be honest, hence do nto want to go down the Eclipse + CDT track.

The main thing I am looking is a decent integration with gdb.

PS : Lately, I have done some iOS development, hence used Xcode and I think it rocks...

root@baikal:~ # cd /usr/ports/editors/codelite/ && make install clean
===> codelite-12.0_4 is marked as broken: outdated, doesn't build with Pango
1.46.2 or newer - PR 249879.
*** Error code 1

Stop.
make: stopped in /usr/ports/editors/codelite
root@baikal:/usr/ports/editors/codelite #
It appear to be broken...
A lot of tools are indeed broken in freeBSD, I am surprised about it.

 

[ahrkahrg]

I'm a big fan of java/netbeans but as its location implies that's mostly because of my Java development. However, Netbeans also supports C/C++ these days and to my understanding also has excellent debugging support (including step traces). Unfortunately I program more with Java than C/C++ so I can't share hands on experience.

Testing netbeans. Interesting chicken and egg situation to use a java netbeans to implement a C solution - remains pragmatic though.
I am a little bit at a loss to configure properly the netbeans to even compile a C/C++ application. Any recommendations or reading you would recommend? I am wndering if this can really be used to compile and build console application and even XWindows application?

 

[ahrkahrg]

With an IDE I should be able to set breakpoints and view variables, but programming serial ports is a bit out of my league. I couldn't see any outputs from any printf's but maybe I couldn't figure out where code:blocks shows outputs. Maybe I'll try using gdb...

An IDE should allow you to manage/build projects into a solution offering an easy a simple syntax highlight edition. Debugging/tracing is a nice to have (like a cherry on a cake) but the cherry does not make the cake to my personal view.

 

[ahrkahrg]

Code blocks opens a separate window for your stdout.

One IDE not yet mentioned is JuCi++. It uses CMake as its build system.

Pros: Well integrated with clang. Where Code Blocks would display some obscure STL template header file while single-stepping the debugger (currently it only knows GDB even when compiling with clang/clang++), JuCi shows me the actual source location in my code. Auto-complete in JuCi makes editing a CMakeLists.txt file much easier.

Cons: UI in JuCi is very barren. A few commands (like clean / rebuild-all or closing out a project), are either not there or not obvious.

Thanks to JuCi, I don't hate on CMake as much as I once did.

> pkg install juci

I have by the way issues running the GBD from code blocks: it simply does not run properly.
Launching the gdb pops a windows with the following information:
'warning: GDB: failed to set controlling terminal: Operation not permitted'
Any idea why?

 

[ahrkahrg]

Thanks a lot for all your feedback. I have tried many IDE available in FreeBSD.
I really would love to develop in FreeBSD, implementing servers, console client and GUI clients.
All I can say is that it is not easy... And I really need your expertise and experience to help me using a decent and easy development environment.

 

[Alain De Vos]

neovim & vscode are nice editors.

 

[drhowarddrfine]

ahrkahrg This thread was started over five years ago and ended four years ago. It would be wise to start a new one.

 

[ahrkahrg]

Thanks a lot for all your feedback. I have tried many IDE available in FreeBSD.
I really would love to develop in FreeBSD, implementing servers, console client and GUI clients.
All I can say is that it is not easy... And I really need your expertise and experience to help me using a decent and easy development environment. I fact

ahrkahrg This thread was started over five years ago and ended four years ago. It would be wise to start a new one.

In the future, in order to avoid such confusion, why not backup and lock the threads forcing newcomers like me to start a new thread.

 

[cracauer@]

I personally find the debugger a tool allowing easy/lazy programming. I believe a true developer should be able to point out a bug or issue using printf on the console. This night be difficult for GUI application but a log file can do the trick. Working without a GBD forces you to think and analyze the code instead of test and try.

You still need the debugger to get backtraces.

And debug by printf, although clearly the most successful general debug method , introduces artificial synchronization in multithreaded code, so sometimes you can't use it.

Then there are undo debuggers that can execute code backwards, which are very useful.

 

[ahrkahrg]

You still need the debugger to get backtraces.

And debug by printf, although clearly the most successful general debug method , introduces artificial synchronization in multithreaded code, so sometimes you can't use it.

Then there are undo debuggers that can execute code backwards, which are very useful.

Personally, I have experienced that debugging in a multiple thread environment, most of the time, the debugger leads you to wrong places. In a multiple thread env. Temporal Logic and a good analysis of the code prevails certainly when you are facing an overrun on one thread jeopardizing another. In that case a debugger is useless (but that is from my experience)