non-gcc dependency flags

Will Partain <[email protected]> Tue, 27 Jan 2004 11:56:09 +0000
Newsgroups gmane.comp.sysutils.ark.devel
Message-ID <[email protected]>
[redirecting a thread to the list...]  An issue raised:

> ... It seems that in thing.py, in dependencyFlags(), the
> compiler/linker "-Wl,-R" is hard-coded, and our linker
> uses a different flag.  If the 'R' case is also for the
> linker, then that -R needs to be changed as well.  How do
> you suggest dealing with machine-dependent complier/linker
> flags.

First: having "all the world's a GCC just like mine" wired
into the code is palpably wrong (but convenient :-), and I
will gladly cooperate in its correction.

But it is worth thinking what you really want.  The Sidai
Way with (shared) libraries is a bit weird [but I like it],
and gives rise to the mess mentioned.  If you don't care for
the Sidai Way, the quickest way forward may be simply to
avoid it.

Here's the Sidai way on libraries... (a) System libraries
are in /lib and /usr/lib, and we don't touch them at all
(but we do use them).  (b) For all other libraries
(Arusha-managed), I want to _specify exactly_ what I want
["berkeley-db--4.2.52"], and I want that stitched together
at build time, and I want it to _stay as it is forever_.
(c) In particular, I do not want programs to wander to
/usr/local/lib and pick up any old thing that they find
lying around -- the standard behavior that many people are
happy with.  (d) I don't want to be meddling with
/etc/ld.so.conf -- I want the binary to know where to get
its stuff.

So the Sidai code proceeds as follows: <constraint>s specify
dependencies on packages (which happen to provide
libraries), and magic code (dependencyFlags) turns that
dependency info into GCC flags that will get the right
compiler/linker flags in at the right places.  It is, of
course, staggering the effort that some packages go to in
order to subvert this plan :-)

If you just don't care about all of this, it's pretty easy
to do what you want.  Imagine you have a package...

   <package name="foo--1.2.3">

   <prototypes>
     <prototype team="sidai" name="ALL" />
   </prototypes>

You could add your own "what I want" layer, perhaps by
saying...

   <package name="foo--1.2.3">

   <prototypes>
     <prototype team="." name="sidai-ALL" />
   </prototypes>

   <!- ......... ->

   <package name="sidai-ALL" prototype="yes">

   <prototypes>
     <prototype team="sidai" name="ALL" />
   </prototypes>

   <compile>
      <!-- no dependencyFlags stuff for us, please -->
      <param name="dep_iflags"></param>
      <param name="dep_lflags"></param>
   </compile>

This is the basic Arusha idea of "same as that guy did,
except for this bit...".

Of course, maybe we need to fix the busted dependencyFlags
...  Let me know.

Will


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn