Re: Should fixinc be linked with libiberty.a?

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: Bruce Korb <korb@datadesign.com>
 > 
 > Jeffrey A Law wrote:
 > > 
 > >   In message <199909062036.QAA12908@caip.rutgers.edu>you write:
 > >   >
 > >   >     I noticed that fixincl is linked with libiberty.a.  I'm
 > >   > wondering whether it should be given host vs build platform concerns.
 > > fixincl is a build tool and should generally be handled like the gen*
 > > programs.
 > > 
 > > Actually, one could claim it does not belong inside gcc itself and that
 > > by having it inside the gcc dir we complicate things.
 > > 
 > > ie, it may be better off outside the gcc subdir much like bison, flex,
 > > texinfo other build tools work.  Nobody ever explained to me the value
 > > of keeping it inside the gcc subdir (much to my aggravation).
 > 
 > Hi Jeff,
 > 
 > I am sorry it has been an aggravation for you.  Originally, it was
 > under contrib because I considered it separate from the compiler.
 > However, the implementation that seemed most straight forward to me
 > was to "install" a script into the gcc build directory.  It turned out
 > that to Manfred, Robert and me that that was most easily accomplished
 > when that directory was ".." (i.e. well known), instead of passed in
 > as an argument to a script that makes it known to a make process for
 > use in _its_ installation rules.  I do not like schizophrenic builds
 > :-).
 > 
 > As far as parallelism with the gen* programs vs. that with bison and
 > other build tools, I am afraid it is still with the gen* tools.  The
 > problem is that there are several unique scripts that are used on
 > certain platforms (e.g. fixinc.winnt).  Until we reach the point that
 > a single source will work for all platforms, the tool to be used will
 > depend on the target platform.  That means it behaves like the gen*
 > programs.  Perhaps a way to address that would be to put a hack into
 > a generic script and have it look for special target scripts.  That
 > would require a change to it once we are rid of special target scripts.
 > Currently, we can just delete them as the logic gets migrated into
 > the definitions file.  (Is it worth doing?  Why?)
 > 
 > So, here are a couple points:
 > 
 > 1.  I don't have any strong preference about it being or not being
 >     within the gcc directory.  My only preference is that it live in
 >     its own directory and that the install mechanism be clean and
 >     comprehensible.  (Where `install' means moving the correct files
 >     into findable place(s).)
 > 
 > 2.  I am inclined to think that the gen* programs should be similarly
 >     isolated, but then I am not into windmill tilting when I can help
 >     it  ;-).
 > 
 > Regards,
 > 	Bruce

Given that you agree with Jeff and say fixincl parallels the gen*
programs, this means to me that we cannot link it with libiberty.a as
it is now.  (I don't see how moving it to the top level would change
that.)  So do we leave it as is or what?

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions