----- Original Message -----
From: Jason Linhart <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 28, 1999 3:22 AM
Subject: Re: [analog-help] Thoroughly confused
> There is very very little of that that would be improved with
> ./configure. The main thing it would fix is the small edits to the
> Makefile for the Sun and a few other platforms. Other than that it is
> going to help very little, make the download larger, make the compile
> time longer, and add complexity.
Those small edits to the Makefile for Sun and a few other platforms is where people
get caught up. Some sites need an install procedure because they don't want to keep
the executables with the source code. Having de-facto standard make targets like
"all", "install" and "clean" are useful and simple.
> configure is not going to magicaly get you a user interface to the
> analog.cfg file without a huge amount of work on Stephens part, and even
> then it would hardly be better than just editing a well commented
> analog.cfg file.
The configuration issue has more to do with using the full capabilities of the make
utility, which includes building, installing, and providing compiler command-line
options like C defines (-D compiler options). With an amount of work (not necessarily
"huge") the configure script can search and prompt for site-specific defaults for a
default analog.cfg file.
> It can't help you with installing because there is no
> installing, you just put Analog anywhere you want, which is totaly better
> than having to run 'make install' as root and worry about where it is
> going to get put and security issues.
One of the great things about configuration scripts is that they provide defaults for
things like install location, configuration location, etc. I would much rather do a
"make install" than a bunch of selective copy commands that an individual may learn
only through trial and error, and having to learn more about the Analog distribution
than they need to. You don't have to do installs as root either, unless that is part
the site's procedure for installing any software. With GNU's Configure scripts, I
usually always use the --prefix option to install software at a different root. And
there's always "make uninstall", or archiving your install log files to deal with
finding out where things have gone.
> There is nothing configure can do about people being confused by the
> difference between file paths and URL paths, such as the IMAGEDIR
> problem. Distribution is hardly an issue at all, and could be better
> handled by some trival additions to the current Makefile.
A configure script that displays a paragraph on what the issue is before prompting
would be helpful. "Trivial" is a relative term, but if you use a template or a tool to
create the Configure script, adding that feature is also trivial.
> The one issue that I count as most misleading, the conflict between when
> to use analhead.h and when to use analog.cfg, which is directly related
> to what started this thread, wouldn't be helped in any useful way by
> configure.
Stephen's response mentioned that you need to change the analog.cfg which overrides
the hardcoded default in analhead.h, which everyone "forgets" to change. This is a
program design issue, not a configuration one. It is of my opinion that all such
hardcoded defaults should be removed from the source, and placed in a configuration
file where it belongs. Besides, a Configuration script would make the appropriate
change in both the source and the default configuration file at the same time.
> If there is an underlying problem with Analog, it is that there are too
> many configuration options, and too many completely different ways to use
> the program.
The problem is not the options and their configuration. The originator of this thread
had two problems - installation location default (or lack thereof), and the wrong
assumption that changing the hardcoded defaults in the source overrides any values in
a configuration file.
> The only complete solution would be a gigantic graphical user interface,
> which would talk almost as long to write as Analog did in the first
> place, and not be at all portable. The configuration tasks it ought to
> perform are way beyond what configure can handle. Take a look at Analog
> Helper on the Mac and tell me how you can handle any of that with
> configure?
"Gigantic" being another relative term. A GUI might be necessary for a "complete
solution" for generating analog.cfg files, but if someone did write it, the
portability issue could probably be taken care of with a Java application, or even a
Java applet that output a config file that you had to manually cut'n'paste. Since a
configure script (for building and providing default values) is most likely to be
terminal line oriented, you're right in that it would be a daunting task to make a
user interface for the complex analog.cfg file. Looking at the Analog Helper
screenshots looks great, and would be portable if they had written it in Java!
> In the short run, I would vote for some reduction in the overlap between
> analog.cfg and analhead.h even if that is just a change in emphisis to
> favor one or the other in the documentation. Second would be a clear list
> of the four or five settings almost everyone has to change that would
> appear in the manual, and in comments in both analhead.h and analog.cfg.
My suggestion is to remove hardcoded values in analhead.h and anlghea*.h completely,
and have all of these settings specified in a default .cfg file, which can be
overridden by another .cfg file and command-line options (like it is now).
And then, I'd recommend using XML and a DTD to store configuration options, and use an
XSL stylesheet to translate it if you insist on using the current analog.cfg syntax.
Could probably create an HTML forms interface from it too. Hmmm ... and ideally,
re-write everything using an object-oriented/modular design, and for cross-platform
usability write it in Java :-) Seriously, if you go the XML way you would need an XML
Parser, which could add to the size of the source code if you decide to package your
own (but why would you when there are free ones available). Then, since your code is
so modular and cross-platform enabled, you could turn it into an Open Source project
and get help from everyone who can and wants to contribute to make Analog the best
log-file analyzer program in the Universe ... which it already is, I know, but there's
room for improvement on everything!
Sorry to ramble on (I wrote this email over a period of the whole day), but the core
of what I'm trying to say is this: to produce brain-dead builds that will work on any
(at least UNIX) platform, use a Makefile generator. To provide an interface that
figures out and/or prompts you for site-specific information, create a configure
script (using GNU's autoconf). To provide an interface for configuring analog.cfg
files, use your favorite text editor or a Helper App. Most importantly, get rid of all
hard-coded site-specific literals from the source code.
cheers,
Simon
------------------------------------------------------------------------
This is the analog-help mailing list. To unsubscribe from this
mailing list, send mail to [EMAIL PROTECTED]
with "unsubscribe analog-help" in the main BODY OF THE MESSAGE.
List archived at http://www.mail-archive.com/[email protected]/
------------------------------------------------------------------------
