Re: c/c++ project management and debugging

[Jason Earl]

On Tue, Dec 21 2010, Rajinder Yadav wrote:

> On 10-12-20 08:28 PM, Andrea Crotti wrote:
>> Rajinder Yadav<devguy.ca@gmail.com>  writes:
>>
>>
>>> yes i already have cedet installed and working, but i would rather not
>>> write makefiles by hand. i understand there is also autoconf that can
>>> be used to generate makefiles, possible that's a better way to go,
>>> still i don't feel like investing the time to learn about autoconf at
>>> this point and time
>>
>> There is also cmake otherwise.
>> The problem is that or
>> - you learn a bit the autoconf skills you need (doesn't take long)
>>    and finally write your own build systems
>> - you'll be stuck forever with what other people (microsoft/cedet)
>>    thik is a good idea, and normally it isn't
>>
>> Using emacs I think it doesn't make any sense to look for tools that
>> write makefiles for you...
>
>
> Andrea, thanks for your reply!
>
> My reply here is not a direct response to you, but what i feel in
> general (a windows IDE guy in a Linux command line world)
>
> I don't quite understand the rational against emacs + auto makefile
> generation, it kind of hinders progress imho? if someone doesn't like
> the way emacs or netbean does things (for them) with makefiles, they
> always have the choice of doing it by hand, that is the beauty of
> having more choices, so stop taking away my choices if I simply ask or
> enquire for feature y!

To a certain extent I think that this is simply due to the fact that
historically Emacs did not handle this sort of task.  So Emacs' users
got used to creating a build system themselves.  Besides, for Free
Software development what you really want is not a simple Makefile, but
some sort of cross-platform build system.  The sort of "build system"
that Visual Studio (or Netbeans, or whatever) generates simply is not
going to work.  In fact, it is probably going to get in the way.

Fortunately, CEDET's EDE actually has pretty good support for
Autoconf/Automake, which despite its flaws, is still probably the most
popular cross-platform build system available.  In short, Emacs is
currently set to make significant progress in this area.

> guys like me from the visual IDE environment will have a smaller
> barrier to entry as a result, overtime we will pickup said skills of
> making a makefile by hand, using autoconf or cmake, etc.

This is precisely why it makes me so happy that GNU Emacs is finally
adding CEDET.  It may not be perfect (yet), but it basically has all of
the parts that Emacs needs to be competitive on this front.  The wacky
keystrokes are still a bit of a barrier for new people, but I personally
think that Emacs is a compelling choice as an editor.  It just needs to
become a better IDE.

> i've never had the need to create a makefile or edit one by hand when
> i code using visualstudio, all i care about is coding my project in
> C++ and getting on with life. people like me need a bridge when we
> come over to the open source world, when we start using linux or
> emacs, etc. most of the time we are met with ridicule about how absurd
> our needs and demands are, so opportunity is lost when some decide why
> bother with open source, etc. el

I agree.  When I learned Linux (and Emacs) I did so because I was a poor
student and I wanted a C compiler and I could not afford one for
DOS/Windows.  I learned to appreciate the GNU development tools, but I
was only willing to put in the time and effort it took to use them
because the alternative was to not be able to develop at all.

> i love ruby on rails hacking, i love doing everything from the command
> line, it's more faster and efficient coding a rails app when compared
> to doing it with netbeans + ide, or whatever IDE is out there!

I honestly think that part of the reason that Emacs has fallen behind
when it comes to acting like an IDE is that a programmer's editor (like
Emacs) and a set of good command-line tools is fairly competitive with
the best an IDE can offer, and it is far more flexible.

Still, a set of tools that help smooth out the learning curve would
certainly help.  CEDET's EDE is actually pretty good in this regard.  It
makes it very easy to create a simple Makefile, and it is still flexible
enough to be useful in fancy Autconf/Automake projects.

The only problem is that CEDET is not (yet) part of Emacs, and so there
are not many examples of how to use its tools.

> i can tell you i spent countless hours searching the net and reading
> stuff just to figure out how to use emacs and get it setup with stuffs
> like ido, ecb, cedet and yasnippet learning all the key binding and
> how to edit the .emacs files, the barrier to entry to become more
> efficient with "emacs" is high

Agreed.  On the bright side the Emacs development team is really trying
to make more frequent releases, and with the next version of Emacs CEDET
will come pre-installed and the ELPA packages already make it easy to
and yasnippet.  I don't use ECB, so I do not know about that.

The fact that Emacs is extensible is a good thing.  The fact that you
essentially have to build your own development environment from scratch
is not a good thing.  I think that this is something that the Emacs
development team is working on, and adding CEDET is certainly going to
help.

> i like having ecb for file browsing, i don't always use it, sometimes
> i use the file searching power of ido, but i have a choice when to use
> which in emacs
>
> i am very grateful to the open source community that has made emacs a
> better tool for me and many more that help answer all my questions on
> mailing list or write blogs.

They are a pretty helpful group, and once you get used to the tools they
do have their strengths.

>>> yes i discovered this gdb setting on the emacs-fu blog, however i
>>> have 2 questions
>>>
>>> 1) when i have EBC opened gdb-many-windows end up looking like a
>>> mess, is there a way to get it to work with EBC?
>>>
>>> 2) i can't figure out how to set breakpoint, can't i simple click
>>> someone in the source window to add a bp?
>>>
>>
>> For a breakpoint you can click, use the space bar or the standard
>> gdb: "b File.cpp:#line" or "b Class::function"
>>
>>
>
> clicking for me doesn't set the breakpoint when i have the source file
> open in the buffer, i am still in edit mode?
>
> i see many gdb windows, but where do I type, b File.cpp:#line ??
>
> here is what i do
>
> 1. open a simple .cpp source file in emacs, a hello world file in C++
> 2. m-x gdb
>
> source buffer disappears, replaced by gdb buffer
>
> 3 m-x gdb-many-windows
> i still don't see my source code window? now where do i click to set a
> break point?
>
> if i switch the gdb buffer to display my source code buffer, i can't
> type in the gdb command while still looking at my source buffer? how
> is one to work in this kind of setup

I don't use gdb-many windows.  I simply do M-x gdb and then when gdb
pops up I do C-x 2 to split the screen, C-x o to jump to the bottom
buffer, and C-x b to jump back to the source screen.  Then I set the
break point with C-x <space> in the source buffer and then use C-x o to
jump back to the gdb window.

I don't use the debugger much though, so I would not be surprised if
there is a better way.

> can i not have a source buffer and a gdb buffer open at the same time,
> still where do i click to set the break point?

I think that even with gdb-many-windows if you took one of the windows
and used C-x b to jump back to the source buffer you could set a break
point.

Jason