Thursday, September 13, 2007

Re: [BLUG] C/C++

On 13/09/2007, Mark Krenz <mark@slugbug.org> wrote:
> On Thu, Sep 13, 2007 at 02:54:25PM GMT, Michel Salim [msalim@indiana.edu] said the following:
> >
> > Not sure it's a good idea to learn a language, an editor *and* a build
> > system all at once!
> >
>
> As opposed to what? Learning Visual studio? Which is a language an
> editor and a build system? I guess I don't see your point. The
> difference is that if she learns vi or emacs, she can carry those skills
> with her other places.
>
I guess you don't see my point indeed. Nowhere did I say I endorse
Visual Studio as a good IDE (it did not even have refactoring support
until, what, 2005?). But if Ana is going to have to use it anyway for
her classes, I don't see why she shouldn't use an IDE that's close in
ease-of-learning.

Plus, there are things about the standard GNU toolchains, especially
the build tools (autoconf/automake) that are quite intimidating (and
at the same time, mundane) at first. KDevelop will generate automake
and autoconf scripts for you:

http://docs.kde.org/development/en/kdevelop/kdevelop/makesystems.html#automake-project

I like using traditional editors too, but I recognise that a modern
IDE has its place: Vi(m)/Emacs for languages and tools you are already
familiar with, KDevelop/Eclipse/etc. for either large projects or for
languages you are still learning (before someone says "Vi/Emacs can do
that too!", let me ask if either has Javadoc / Ndoc support)

--
Michel

--
Michel
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] C/C++

On Thu, Sep 13, 2007 at 03:05:13PM +0000, Mark Krenz wrote:
> On Thu, Sep 13, 2007 at 02:54:25PM GMT, Michel Salim [msalim@indiana.edu] said the following:
> >
> > Not sure it's a good idea to learn a language, an editor *and* a build
> > system all at once!
> >
>
> As opposed to what? Learning Visual studio? Which is a language an
> editor and a build system? I guess I don't see your point. The
> difference is that if she learns vi or emacs, she can carry those skills
> with her other places.

You can start with any editor. Screen can help a lot. Have one screen
window allocated for a shell to run make and test the program. Have one
screen window allocated to run 'man' on functions. Then have two or more
screen windows allocated for editing files.

This is still frequently the way I prefer to develop. It is easily portable
to any editor. (And I have used several.)

Most build systems are very easy for simple things. GNU Make is actually
less easy than much of the competition, however it is easy for people to
do simple things poorly so people fail to understand how they're misusing
it. (Make is the reason there are so many "make" alternatives.) The big
benefit of knowing a little about it is that it is so commonly available.

GUI develoment environments have been popular since the development of
EMACS (the first IDE). All other IDEs were first attempts at gaining a
subset of the features available in EMACS. If you want a complete IDE,
you may want to learn EMACS.

Please note: Anyone in their right mind will tell you that MS Visual
Studio has some unmatched debugging features. You won't be able to find
anything coming very close to the features, if that is your standard.
Like many applications, while extra features can be nice, they're not
actually needed to get work done. You may be surprised with how many
projects use printf() for debugging.

The more graphical heavy development environments have their place,
certainly, however most people will eventually need to do some remote
debugging, remote development, or remote testing. You will likely need
to become comfortable in an environment with TTY access. You may as
well start now. Even for GUI development, if you manage to properly
seperate your application logic from the GUI interface it can greatly
increase testing options. Command-line tools are more easily automated,
and a seperate library for the application logic allows a variety of
interfaces to be made available -- including text-based interfaces.

Cheers,
Steven Black

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] C/C++

#!/usr/bin/env make
# This should be called Makefile or makefile
# This simple makefile was released anonymously in to the public domain.
# Note: This isn't expected to work with GNU Make < 3.79 or other non-GNU makes

## Your list of sources
## *.c - C source code
## *.cpp / *.cxx / *.cc / *.c++ / *.C - C++ source code
SOURCES:=test.c

## The name of the executible
TARGET:=test

## Used to compile your C sources
CFLAGS:= -Wall
## Used to compile your C++ sources
CXXFLAGS:= -Wall
## Used to specify C preprocessor flags
# CPPFLAGS:= -DMY_VALUE="defined"
CPPFLAGS:=

## Used for the final link for the executible
# LDFLAGS:= -lm
LDFLAGS:=

# Any additional files you want to remove can go here
CLEANFILES:=

### Some customization flags

## How are capitalized extensions handled?
# Indicates whether the capitalized letter is 'normal' (C++, etc.),
# or the 'same' as the uncapitalized version.
CAPMODE:=normal

## The default target is what is run when no target is specified.
# Historically 'all' is the default target. In our case, 'all' is
# mapped to this DEFAULT_TARGET. Sane settings for this would be
# 'help' or 'build'.
DEFAULT_TARGET:=help

### Over-ride some settings provided by Make.

# We want to use GCC where possible
CC:=gcc
CXX:=gcc
# x86 Linux systems prefer gcc to be used as the linker
LD:=gcc

### End of user-servicable parts

# Now, do not let targets mess with our pseudo-targets
ifneq ($(filter-out /%,$(TARGET)),)
TARGET:=$(addprefix ./,$(TARGET))
endif

DEFAULT_TARGET:=$(strip $(DEFAULT_TARGET))
ifeq ($(DEFAULT_TARGET),)
DEFAULT_TARGET:=build
endif

all: $(DEFAULT_TARGET)
.PHONY: all build
build: $(TARGET)

.PHONY: help
help:
@echo "The following targets are available:"
@echo " help: this help message."
@echo " build: build the TARGET: $(TARGET)"
@echo " clean: clean the directory"
@echo " tar.gz: create a .tar.gz from current directory"
@echo " tar.bz2: create a .tar.bz2 from current directory"

OBJECTS:=$(addsuffix .o,$(basename $(SOURCES)))
CLEANFILES := $(wildcard $(addsuffix .d,$(basename $(SOURCES))) $(filter-out $(filter %.o, $(SOURCES)),$(OBJECTS)) $(CLEANFILES) $(TARGET))
.PHONY: clean
clean:
ifneq ($(CLEANFILES),)
$(RM) $(CLEANFILES)
endif

$(OBJECTS): $(filter-out %.d, $(MAKEFILE_LIST))

ifeq ($(notdir $(CC)),gcc)
# -MD or -MDD should provides us the .d dep files on demand
ifeq ($(filter -M%,$(CPPFLAGS)),)
CPPFLAGS:=$(CPPFLAGS) -MD
endif
endif # ... gcc

.PHONY: tar.gz tar.bz2

TAR_DIR=$(notdir $(shell pwd))
TAR_BASE=$(TAR_DIR)_$(shell date +'%Y-%m-%d_%H-%M').tar

tar.gz:
tar -zcvf ../$(strip $(TAR_BASE)).gz -C .. $(TAR_DIR)

tar.bz2:
tar -jcvf ../$(strip $(TAR_BASE)).bz2 -C .. $(TAR_DIR)

# Please note: We leave the dependancies mostly up to the built-ins

$(TARGET): $(OBJECTS)

ifeq ($(CAPMODE),same)
# Normally we let GCC auto-determine the type of source code. In this case
# we force the matter with "-x".
# Note: This is based on GNU Make 3.81 built-in logic. See make -p for more
%.o: %.C
$(COMPILE.c) -x c $(OUTPUT_OPTION) $<

endif

# -MD creates per-file dependancy files which we can include
# If you're not using GCC, then the dependancies will never be right unless
# you alter the makefile logic.
ifneq ($(filter clean, $(MAKECMDGOALS)),clean)
-include $(addsuffix .d,$(basename $(SOURCES)))
endif

# end of Makefile

On Wed, Sep 12, 2007 at 09:24:39PM -0400, Pawsitive Results wrote:
> What tool/tools would you suggest I start with, to follow along on the
> Linux side? I suspect I'll learn better, if I'm more able to mentally
> separate the task from the tools (if that makes sense).

Both Emacs and Vim have good syntax highlighting and overall development
support. Most people will be aware of the Emacs support, though the VIM
support is probably a little less well known. (Vim has a :make command,
which will work nicely if you have a Makefile.)

Speaking of Makefiles, they can be a bit intimidating. For starters, you
can use the attached simple makefile. You should check out the GNU Make
info documents for details.

Cheers,
Steven Black

Re: [BLUG] C/C++

On Thu, Sep 13, 2007 at 02:54:25PM GMT, Michel Salim [msalim@indiana.edu] said the following:
>
> Not sure it's a good idea to learn a language, an editor *and* a build
> system all at once!
>

As opposed to what? Learning Visual studio? Which is a language an
editor and a build system? I guess I don't see your point. The
difference is that if she learns vi or emacs, she can carry those skills
with her other places.


--
Mark Krenz
Bloomington Linux Users Group
http://www.bloomingtonlinux.org/
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] C/C++

On 12/09/2007, Pawsitive Results <pawsitiveresults@gmail.com> wrote:
> As some of you know, I'm taking the beginning C/C++/C# class at Ivy
> Tech this semester, in which we're using Microsoft Visual Studio 2005.
>
> What tool/tools would you suggest I start with, to follow along on the
> Linux side? I suspect I'll learn better, if I'm more able to mentally
> separate the task from the tools (if that makes sense).
>
For a more similar experience with Visual Studio, I'd suggest KDevelop
or Anjuta -- both are graphical IDEs like Visual Studio, and I think
the Makefiles they generate should be quite readable.

Not sure it's a good idea to learn a language, an editor *and* a build
system all at once!

--
Michel
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] C/C++

By the way, if you want to see that small clip that I used to explain
the philosophy of that, check this out:

http://www.youtube.com/watch?v=oXnzstpBEOg

This is another one I showed, not related to editors:

http://www.youtube.com/watch?v=zbkizy-Y3qw

ripped using mencoder:

mencoder dvd://3 -chapter 5-6 -slang en -subdelay 1 -ovc lavc \
-lavcopts vpass=1 -oac mp3lame -af volume=10 -o output.avi

On Thu, Sep 13, 2007 at 02:25:32AM GMT, Gillis, Chad [rcgillis@indiana.edu] said the following:
> Hi Ana,
>
> Is a good text editor "an extension of your hand" yet? (Quote is from
> Mark's presentation yesterday.) If not then you might want to start as
> early as possible becoming really familiar with the keybindings of one
> of the big two.
> Make sure that the config file for the editor is set up to recognize
> syntax. That way it will help to point out errors, indent
> automatically etc.
>
> It's probably also a good idea to become accustomed to compiling using
> make, just to get into the habit and become familiar with the syntax,
> even if you're only compiling simple programs.
>
> Also, a popular debugger is gdb. Having said that, I haven't gotten as
> much use out of it as I'd like to pretend.
>
> Hope it works out. In reality, all you need is a good text editor
> that's well-configured, g++ and a command line.
>
> Chad
>
> Quoting Pawsitive Results <pawsitiveresults@gmail.com>:
>
> >As some of you know, I'm taking the beginning C/C++/C# class at Ivy
> >Tech this semester, in which we're using Microsoft Visual Studio 2005.
> >
> >What tool/tools would you suggest I start with, to follow along on the
> >Linux side? I suspect I'll learn better, if I'm more able to mentally
> >separate the task from the tools (if that makes sense).
> >
> >Bear in mind this is my first venture into any kind of programming
> >whatsoever. (Unless you count BASIC on a TRS-80 Model III, back in
> >high school.) So simpler, more basic tools probably make the most
> >sense.
> >
> >Ana
> >_______________________________________________
> >BLUG mailing list
> >BLUG@linuxfan.com
> >http://mailman.cs.indiana.edu/mailman/listinfo/blug
> >
>
>
>
> _______________________________________________
> BLUG mailing list
> BLUG@linuxfan.com
> http://mailman.cs.indiana.edu/mailman/listinfo/blug
>

--
Mark Krenz
Bloomington Linux Users Group
http://www.bloomingtonlinux.org/
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug