C Anyone use Eclipse CDT to develop on FreeBSD?

  • Thread starter Deleted member 63822
  • Start date
D

Deleted member 63822

Guest
I can't get CDT to work. It doesn't detect both Clang and GCC. What I have are CrossGCC and XL C++ Compiler, and I have no idea about the later. On Linux, select CrossGCC means you need a GCC cross compiler, which I don't have any on this system. Don't know if it's the same on FreeBSD. About the XL C++ Compiler, anyone could let me know WTF it is, please?

On Linux, I use this IDE which is a custom build of Eclipse CDT and their own tweaks. Sadly, it doesn't have a FreeBSD version and it seemed it's closed source: https://cevelop.com/

I found the appearance of CDT on FreeBSD is a bit weirded indeed. I have used plain CDT on Linux (to compare with Cevelop but finally I go for Cevelop), but it doesn't look like CDT on FreeBSD at all.
 
Please note that I have installed GCC from pkg but it still doesn't detect this GCC. I also have the LLVM compiler family plugin installed, too, but I didn't have any LLVM entry on my Preference window. The plugin seemed to not work at all.
 
I know nothing about CDT but is it some form of "wizard" that looks for gcc and/or clang? Is there some configuration file you can manually edit to add them? Perhaps you need to seek help from the eclipse web site?
 
AFAIR Eclipse 3.1 was my first and last encounter with Eclipse. I wanted to learn Java 5. Both of them was a dead-end. If you want to use a well-supported full-feature IDE, try VSCode.
 
I haven't tried Eclipse. I used to use NetBeans, but that is dead-ish ATM for C and C+. I use Qt Creator currently, but VSCode looks good. And I might try CLion one day.
 
  • Like
Reactions: a6h
I just tried Netbeans 11.3 - which I'd forgotten I had installed already. After downloading the C++ plugin, I could run a sample cmake project. It picked up clang as the default.

Eclipse CDT wanted half a gig to install and didn't like any of the C/C++ compilers already installed. I promptly removed it.
 
I think IDEs are a little old fashioned and tend to glaze over when discussing them. However this one actually caught a bit of interest:

https://github.com/cppit/jucipp

Rather than try to support a wide range of compilers and debuggers (which end up just making the whole thing a bit sloppy and fragile), it decided to focus entirely on Clang.

A small and light IDE is... oddly unique as a concept.

But, I think I'm gonna stick to (n)vi like God intended XD
 
  • Like
Reactions: a6h
I am mostly using devel/geany. It's not really an IDE but it generally does what i want/need. If i absolutely need a graphical debugger i use https://wiki.gnome.org/Apps/Nemiver. It's kinda quirky/buggy but it tends to more or less work even if i am not overly happy with it. It seems there is no FreeBSD port for it yet though and i also have no idea if it would work with lldb.
 
But, I think I'm gonna stick to (n)vi like God intended XD
I saw the light too. I'm perfectly fine with nvi(1). I have /root/.exrc and ~/.exrc every where: FreeBSD, FreeBSD on VM, etc.

.exrc
Code:
set number
set ruler
set showmode
set ignorecase
set noshowmatch
set tabstop=2
set shiftwidth=2
set wrapmargin=0
set nolist
set autoindent
set hardtab=2
 
A small and light IDE is... oddly unique as a concept.

If you're working on a large project, in particular C++, then if you want to have a full 'view' of the code then the dev environment needs to know an awful lot if information if you want to be able to do things like
  • jump between uses, definitions and declarations
  • navigate class hierarchies
  • find all uses
  • see macro expansions
  • any refactoring
  • code completion
I don't know how well modern vim copes with all that via plugins.
 
I don't know how well modern vim copes with all that via plugins.

It doesn't ;)

The trick is to remember you are not constrained to one tool. The UNIX development environment is made up of a lot. Cscope, ctags, grep, even more modern ones like doxygen give a good overview. I personally find these tools far superior at navigating large codebases made up of multiple projects than what I have found in an IDE. That could just be my familiarity with them though.

Try to stay away from vim and plugins. That again just funnels you into the view that you have to use one tool and do everything within it. (n)vi and tmux is fine here.

Many IDEs are particularly bad at working with multiple languages at once. For example can you refactor a C++ function and have it update your Java bindings at the same time?

As for code completion. If you are working with non-OOP languages like C, it can't really work. There are no functions stored inside the structures and most of the time you only have an opaque pointer anyway.

Unless of course you mean the IDE adding white-space or bracers. In which case, I work on *far* too many projects to teach the compiler what coding standards I need it to adhere to for each one.

The worst one for me is that IDE users generally have to hop around. I.e Visual Studio is crazy popular on Windows and yet for some of my collegues to play with Rust they need to use an entirely different IDE to wait for VS to catch up. Being able to change environment like that kinda just suggests they weren't happy with it in the first place.

We also use Emscripten C++ a lot at work. None of us have really ever found an IDE that works properly with it. Same with a lot of the Playstation SDKs. (They occasionally offer a plugin for Visual Studio 6 XD).
 
As for code completion. If you are working with non-OOP languages like C, it can't really work. There are no functions stored inside the structures and most of the time you only have an opaque pointer anyway.

Auto complete is overrated. Some implementations are overzealous to the point of harming productivity.

For C, suggesting structure member names following a dot or pointer dereference or suggesting local variable names is nice so it's not a total loss.
 
It doesn't ;)

The trick is to remember you are not constrained to one tool. The UNIX development environment is made up of a lot. Cscope, ctags, grep, even more modern ones like doxygen give a good overview. I personally find these tools far superior at navigating large codebases made up of multiple projects than what I have found in an IDE. That could just be my familiarity with them though.

I do use vi, grep and Doxygen. Pretty much all IDEs will do a global regex search. Some will even show the Doxygen markup dynamically in a tooltip, plus most of the rest that Doxygen does (call graphs, include graphs), with the ability to parse modern C++ as well. Not that I get much chance to use modern C++.

Many IDEs are particularly bad at working with multiple languages at once. For example can you refactor a C++ function and have it update your Java bindings at the same time?

Java, what's that?

As for code completion. If you are working with non-OOP languages like C, it can't really work. There are no functions stored inside the structures and most of the time you only have an opaque pointer anyway.

Really? As an example in Qt Creator I can type "spr" then enter to accept "sprintf". A popup then shows me the full signature. That's a trivial example, but it's definitely useful in the >6MLOC codebase at work.
 
I do use vi, grep and Doxygen. Pretty much all IDEs will do a global regex search. Some will even show the Doxygen markup dynamically in a tooltip, plus most of the rest that Doxygen does (call graphs, include graphs), with the ability to parse modern C++ as well.
...
As an example in Qt Creator I can type "spr" then enter to accept "sprintf".

I think that is kinda the problem. Your IDE of choice might have that function whereas many others do not. And they might then have another function which yours does not. What do you do? Run 3-4 IDEs in a project?

I suppose you could half use an IDE and then resort to the command line for the remaining missing functionality, however I find that kind of context switching a little awkward and would rather a single consistent environment.

Java, what's that?
Apparently it is a stupid *shim* that is required for the Android platform to communicate with the underlying OS because their C-runtime via NativeActivity is horrifically lobotomized. It shouldn't exist but sadly does :/
 
Back
Top