[sac-dev] inc/proto.h patch

[Brian Savage]

George

Submitting patches works in this manner (As I see it).  If you have a 
patch to contribute, send it to the mailing list. Create the patch using 
  "diff -u ".  If the patch looks ok and is testing it ok, than it can 
be committed.  I think only a few people have CVS write premission 
(Peter for example).  The people with premission will submit the patch, 
if you cannot.  Does this sound correct/reasonable ?

Back to the patches:

I understand the /sw/lib and /swinclude problem with the older versions 
of OSX.  In that case, you solution will work fine.

Concerning OSTYPE.
Setting OSTYPE in bash and then exporting it does not work ?  I would 
expect something like
export OSTYPE=darwin6
to set this variable in subordinate shells.  Correct me if I am wrong.
I would also look info MAKEFLAGS to see if it is available/appropriate.


Cheers,
Brian

George Helffrich wrote:
> 
> On Wednesday, November 30, 2005, at 03:01 PM, Brian Savage wrote:
> 
>> George
>>
>> I like you proto.h patch.  All the #define within the code need to be 
>> wrapped with #ifdef.  Something to do in the future.
>>
>> Thanks for testing the source on a different platform.  I have a 
>> couple questions about the makefile patch.
>>
>> First, I noticed that you created a new variable like
>> MK = MAKE OSTYPE=$OSTYPE
>> Is setting OSTYPE=$OSTYPE within SACCFLAGS more appropriate ? Plus, is 
>> there something on your system that depends on OSTYPE.
> 
> 
> On available evidence, bash apparently sets OSTYPE only for login 
> shells.  Subordinate shells invoked by recursive make don't set it.  
> Hence it has to be explicitly passed in the make environment.  This only 
> makes the make process work right.
> 
>>
>> Second, what in particular is in /sw/lib and /sw/include that is 
>> required by SAC?  I would prefer if these -I and -L were included in 
>> the darwin OSTYPE section.
> 
> 
> Sadly, 10.2 did not provide a standard routine interface for dynamic 
> loading, so it comes from Fink.
> 
>>   We can automatically determine where these libraries are at the 
>> beginning of the make process or wrap the entire process in a 
>> configure script to do the same thing.  Or did I read your patch 
>> incorrectly ?
> 
> 
> Configure script would be better long term solution and would simplify 
> the make file, but this works for now.  The build process has an N**2 
> makefile architecture regarding ar modifying lib/sac.a that is more of a 
> nuisance to my mind.
> 
>>
>> Cheers,
>> Brian
>>
> 
> What is the procedure for committing patches, i.e. who has CVS write 
> privileges?  I posted these patches to get these policy questions sorted 
> out.
> 
>                                 George Helffrich
>                                 george at geology.bristol.ac.uk
> 
> _______________________________________________
> sac-dev mailing list
> sac-dev at iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/sac-dev