Thread: inc/proto.h patch

Started: 2005-11-30 18:02:05
Last activity: 2005-12-01 01:26:34
Topics: SAC Developers
George Helffrich
inc/proto.h patch
2005-11-30 18:02:05
This patch eliminates warning messages when building on MacOS X 10.2
systems




George
Attachments
  • Brian Savage
    Re: inc/proto.h patch
    2005-11-30 18:01:51
    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.

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

    Cheers,
    Brian


    George Helffrich wrote:
    This patch eliminates warning messages when building on MacOS X 10.2
    systems




    George


    ------------------------------------------------------------------------

    _______________________________________________
    sac-dev mailing list
    sac-dev<at>iris.washington.edu
    http://www.iris.washington.edu/mailman/listinfo/sac-dev


    • George Helffrich
      Re: inc/proto.h patch
      2005-11-30 23:23:10

      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


      • Brian Savage
        Re: inc/proto.h patch
        2005-11-30 19:29:21
        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


        • George Helffrich
          Re: inc/proto.h patch
          2005-12-01 01:26:34

          On Wednesday, November 30, 2005, at 04:29 PM, Brian Savage wrote:

          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 ?

          It sounds reasonable, but I don't see other patches or commits reviewed
          this way. Is the process symmetric?


          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.

          Please, let's not debate *user* workarounds to the build problem; I am,
          um, moderately conversant with the shell and know how to surmount the
          issue in comparable ways to what you propose. What the patch aims to
          do -- and does -- is to make the build work out of the box for the
          impatient and uninitiated builder. This is the environment and OSTYPE
          value that OSX 10.2 presents to that user, and, I think, the spirit of
          the readme text.

          I will try to commit the include patch and wait on a verdict on the
          makefile one. Then, hopefully, we can move discussion to development
          issues rather than lessons on shell use. Please?


          George Helffrich


NSF SAGE Facility has been certified as a trustworthy data repository by the CoreTrustSeal Standards and Certification Board
08:36:29 v.3514fbed