[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avrdude-dev] Re: About avrdude-gui
From: |
Joerg Wunsch |
Subject: |
Re: [avrdude-dev] Re: About avrdude-gui |
Date: |
Mon, 31 Oct 2005 20:53:46 +0100 |
User-agent: |
Mutt/1.4.2.1i |
As Henrik Brix Andersen wrote:
> May I suggest making a shared library (libavrdude) instead, then
> external projects (fltk-avrdude, gavrdude, kavrdude, ...) can link
> against that library to provide a GUI for avrdude.
I don't think that makes any sense, for the following reasons.
. You could already start using the current project, and consider its
.o files a library (though it's not a .a file). They could be
organized a bit better (e.g. in some subdirectories), no argument
here, but that shouldn't hinder you starting your project.
. A *shared* library only makes sense if there's something to share at
all. The point is not whether some .o files could be shared, but
whether more than one application will use it by the same time.
That's very likely not the case. But then, there's no point in
making a shared library (other than it appears to be popular these
days). It will only increase maintenance effort (regardless of how
little it might be using some fancy tool, compared to zero, it will
always be more), and the PIC requirements will produce poorer code
in particular on architectures like the i386 with its permanent lack
of free registers available to the compiler.
. Finally, there's no point in wasting developer's resources by
starting more than one GUI project at the same time. Sure, it might
make sense to start skeletons of each, just to be able to compare
them, but after that, gentlemen, please discuss the pros and cons,
and agree on a single approach but do it well instead.
As Bernard Fouché wrote:
> As for a command-line only or a gui-version, I'd prefer to have 2
> executables, one GUI and one CLI, at least to be able to
> compile/link avrdude on a computer without having to install tens of
> different packages (pango/wxdigets/gtk2, etc).
configure should be able to take care of that. My idea is that by
default, no GUI should be configured, in the same light as no
(texinfo-based) documentation is built by default: to keep the number
of prerequisites minimal.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)