[[ Form of ... a forest fire! ]]
%% "Barry A. Warsaw" <bwarsaw_at_newcnri.cnri.reston.va.us> writes:
baw> Right! Since we install all of our net-contrib'd X software in
baw> `non-standard' places (i.e. not /usr/openwin/bin on Solaris),
baw> one of the first things I had to do is copy all the OpenWindows
baw> imake config files and hack them up so they'd reflect our
baw> environment. Now that I've done this, most X programs build
baw> fairly painlessly.
Sure... as long as you always want to put them in the same place. What
if you want to put them into _different_ places? Do you have to go back
and hack up the config files again? How do you handle switching back
and forth?
I sometimes want to install imake-based apps into the X release
directory, and sometimes into our "global" contrib software directory,
and sometimes other places (our source tree, perhaps, if it's a tool or
something). It's next to impossible to do this with imake. I've posted
many queries for help and guidance to the X newsgroups, and received
many "me-too" responses, but as of yet I have not received one _single_
suggestion on a solution.
Imake is dated, crufty technology that's marginally useful for building
X... period. IMHO of course :)
I'd prefer it if X went to autoconf too: autoconf has one GIGANTIC
advantage over imake that basically makes this entire conversation
silly: autoconf gracefully handles building source for multiple
architectures at the same time, without conflict. I always do this with
all autoconf packages:
$ tar xofz package-500.tar.gz
$ cd package-500
$ mkdir _sun4
$ cd _sun4
$ ../configure --prefix=/usr/global
$ make
Then, I login to my HP, and do this:
$ cd package-500
$ mkdir _hp9
$ cd _hp9
$ ../configure --prefix=/usr/global
$ make
all at the same time, of course.
With imake, I have to build for one, install, clean, then build for the
next, install, clean, etc. If I find a problem with the first one, I
have to clean out the current one, rebuild everything over. With
autoconf, I have all the architectures there already built; I just
recompile the one file that changed and relink.
X's symbolic link farm solution is crufty at _best_, and only works with
X--it doesn't translate automatically to all packages which use imake.
(To be fair, it can be tricky writing your autoconf Makefile.in to work
with the multi-architecture feature correctly if you're not familiar
with VPATH, but at least it's supported and there are lots of good
examples).
%% <matusita_at_ics.es.osaka-u.ac.jp> writes:
grossjoh> ./configure --with-x\
grossjoh> --x-includes=/usr/local/X11R6/include\
grossjoh> --x-libs=/usr/local/X11R6/lib
mm> I think it is too tired :-) Editing *akefile and execute appropriate
mm> command of what you want. It's simple :-)
Uhh... really, really NOT! :)
What do I edit? Who knows? The Imakefile just says
"InstallSimpleCommand()" or some such thing. No path, no nothing.
What if I want to install it somewhere else? What if I want it to build
with an install path of /foo/bar, but when I run install I want to stage
it into a directory /local/beta/foo before actually installing it (I do
this all the time)?
mm> Somebody says GNU configure is flexible because of command-line
mm> option, but it's unflexible because of command-line ONLY. Editing
mm> *akefile after 'sh ./configure' is out of the questions :-)
Why? Makefiles generated by autoconf are trivial to edit for changes
like this--a far sight simpler than editing a postprocessed imake
Makefile, no doubt about that! Imake generates makefiles with 10 pages
of boilerplate stuff at the beginning, and you can't tell which variable
to change for which path: there seem to be two or more for every
purpose. I'm constantly searching back and forth through the makefile
trying to figure out where variables got their values from and which one
I should change.
Then half the time the actual make rules at the bottom of the makefile
don't even use the boilerplate variables! And when they do, they often
use the same variable for so many different things that you can't get it
to do what you want.
With imake, about 70% of the time I end up thinking it'd be easier to
just write my own makefile, and I sometimes do. With autoconf, I can't
remember _ever_ thinking that, much less doing it.
Autoconf makefiles all have a nice little section at the top like this:
# Common prefix for machine-independent installed files.
prefix = /usr/global
# Common prefix for machine-dependent installed files.
exec_prefix = ${prefix}
# Directory to install in.
bindir = $(exec_prefix)/bin
# Directory to install the Info files in.
infodir = $(prefix)/info
# Directory to install the man page in.
mandir = $(prefix)/man/man$(manext)
# Number to put on the man page filename.
manext = 1
Everything is based off of $(prefix). Trivial to change the entire
thing by resetting $(prefix), or you can tweak them individually for
greater flexibility.
I usually just override them on the make command line. E.g., to do what
I mentioned above and stage the installation is trivial:
$ ./configure --prefix=/foo/bar
$ make
$ make install prefix=/local/beta/foo
Done. I never even bother to _look_ at the makefile. Plus, autoconf
packages come with some darn documentation (the INSTALL file); almost no
imake packages tell you how to customize the install directories, etc.
mm> Using GNU configure as a default is easy. But it's less
mm> flexible when we want to use 'site specific' setup.
I couldn't disagree more. Imake is unfriendly, inflexible, confusing,
difficult to use even in the simple case, impossible to use for more
complex cases, and _way_ to big and complex for what you get (who needs
all that for a few simple pathname settings and a compiler name for
pity's sake? Autoconf actually _works_ for its money, producing a
customized config.h file or whatever :)
Autoconf has its problems, but it's far and away the very best choice
out there.
Go ahead, ask me how I _really_ feel! :)
[[ Shape of -- a glacier! ]]
-------------------------------------------------------------------------------
Paul D. Smith <psmith_at_baynetworks.com> Network Management Development
Senior Software Engineer Bay Networks, Inc.
-----------------------------------------------==<
http://www.baynetworks.com/>-
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions--Bay Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Thu May 23 1996 - 12:37:07 BST