I realize that this is way off topic and this will be the last I say,
but I'll say it again--what you're talking about is a task that is
supposed to be done by the _developer_.  Not the end user.  The end user
should not have to worry about rebuilding configure or Makefile.in.  In
fact, this only gets in the way.  If I, a developer, forget to run
automake -i; autoconf ; perl admin/am_edit before I do "make dist", then
shame on me.  I should be spanked, flogged, etc. appropriately, because
that's my job and I messed up doing it.  My end users should not be punished 
by having "make" even know _how_ to do anything other than make the 
executable.  What bothers me is the lack of a clear separation between
"hey, I'm a developer and I need to put an environment together for
people to be able to compile this thing" and "hey, I'm an end user who
doesn't need to, want to, and shouldn't be concerned with creating a
'configure' script that allows me to compile this beast--in fact, all I
want to do is compile this program".

End of digression, 'nuff said, etc.  =:)



* [09/26/01 16:35] Of all the gin joints in all the towns in all the world,
* Jeffrey Taylor <[EMAIL PROTECTED]> walks into mine and says: 

> So that when the developer touches any one of the 10,000 files, INCLUDING
> Makefile.am, all dependencies are rebuilt.  I have a project with 890
> source files, including 23 Makefile.am files.  This self-reflective make
> process is a lifesaver.  Yes, it eats up more CPU than strictly
> necessary 99% of the time and saves me from shooting myself in the
> foot that other 1%.  Kind of like using "-Wall -ansi -pedantic
> -Wmissing-prototypes" in GCC.
> 
> HTH,
>   Jeffrey
> 
> Quoting Jason Kasper <[EMAIL PROTECTED]>:
> > Actually, after digging into the black arts of auto*, I can say that
> > it's automake that is doing this.  If you take a very simple Makefile.am
> > and run automake against it, automake will happily generate a
> > Makefile.in that knows how to rebuild config.h, configure, Makefile,
> > Makefile.am, and Makefile.in.  Why, I have NO bloody idea.  
> > 
> > My solution in bbconf is to use a quick perl regexp to strip all this
> > garbage out of every Makefile.in before configure is run against it to create
> > the Makefiles.  The end result (be it the correct path or not I don't
> > know) is that make has absolutely no clue on how to create config.h,
> > configure, Makefiles, or anything else that it shouldn't.  The regexp is
> > as follows...
> > 
> > $MakefileData =~ s/SUFFIXES.*mostlyclean-hdr:\n/SUFFIXES:\n\nmostlyclean-hdr:\n/sg;
> > 
> > ... and seems to work well enough.
> > 
> > My question (for the 2 millionth time in the last 10 days) is why, oh
> > why, oh why, does automake think it needs to tell "make" how to rebuild
> > the things that are telling "make" what to "make"?
> > 
> > Anywho, the bug is fixed in bbconf.  I'd just like to understand the
> > logic behind it being put there from "automake" in the first place. 
> > 
> > *poof*
> > 
> > 
> > * [09/17/01 02:09] Of all the gin joints in all the towns in all the world,
> > * Sean 'Shaleh' Perry <[EMAIL PROTECTED]> walks into mine and says: 
> > 
> > > On 17-Sep-2001 Jason Kasper wrote:
> > > > I wholeheartedly agree.  If anyone can shed light on this annoyance (and
> > > > enlighten me in the process), I'd be rather grateful.  
> > > > 
> > > > ./configure should ONLY do that--configure what's already been
> > > > automake'd, autoconf'd, and "perl admin/am_edit"'d.  Why it insists on
> > > > doing it over and over and over again purely annoys the snot out of me.  
> > > > 
> > > > Anyone have any magic or level of clue greater than mine into the dark,
> > > > mystical world of auto* on what potions I need to conjure, dark wibble
> > > > dances I need to dance or otherwise to get rid of this bothersome habit?
> > > > 
> > > 
> > > My guess is the admin/ magic with configure.in.in files.  This causes
> > > configure.in to change and this causes make to believe the autotools need to be
> > > re-run.
> > > 
> > > Why on earth the kde tool wants to make this so unbelievably complicated is
> > > beyond me.  I hope to understand autotools better in the coming week(s) and
> > > hopefully will be able to stear people better.
> > 
> 
> -- 
> I don't do Windows and I don't come to work before nine.
>                -- Johnny Paycheck

-- 
----%<----------%<----
Jason Kasper (vanRijn)
bash$ :(){ :|:&};:
Numbers 6:24-26

Reply via email to