Re: non-gcc dependency flags

Since I was using try-ark, I had to override <configure> and 
<install-bits> in addition to <compile>.  And since the packages, for 
example, gzip, calls sidal's gzip, which then calls GNU, and GNU 
defines <configure>, I had to put my override prototypes before calling 
sidal's gzip, rather than just adding the overrides to myteam1's ALL.

However, I would thing that fixing the "busted dependencyFlags" would 
be a useful future enhancement, particularly given the variety of 
unices out there.

Edward Moy
[email protected]
---------------------------------------------------------------
(This messages is from me as a reader of this list, and not a statement 
from Apple.)

On Jan 27, 2004, at 3:56 AM, Will Partain wrote:

> [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.



-------------------------------------------------------
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