Loading ...
Sorry, an error occurred while loading the content.

Compile versus Run Time for gmfsk

Expand Messages
  • w1hkj
    Hamish etal, My original intent with the gmfsk mods was to provide a way to conveniently test changes to the application that would eventually be incorporated
    Message 1 of 4 , Apr 12, 2006
    • 0 Attachment
      Hamish etal,

      My original intent with the gmfsk mods was to provide a way to
      conveniently test changes to the application that would eventually be
      incorporated into the mainstream gmfsk source tree. That has not
      happened. Tomi Manninen, OH2BNS, the author of gmfsk has not been
      available to discuss the mods. So I am left with an unwanted dilemma.

      I have been considering the issue of whether to change the compile time
      modifications to permanent code changes whose features can be enabled
      and/or modified by configuration dialogs. That would satisfy the Debian
      distribution problem. I think that this would require renaming the
      application since it would not then be as tightly linked to the original
      gmfsk.

      I know that Ed has been having some problems getting the .48 version to
      recognize his hamlib install at compile time. A Debian distro would
      probably help him out of the compile dependency issue. Has anyone else
      experienced similar compile-time problems?

      I would appreciate hearing from the present users of gmfsk on this
      idea. What mods do you incorporate? Which ones should be retained and
      which discarded? How difficult do you find the compile time decision
      tree that you need to navigate via the hkj-config.h file

      Dave (hkj)
    • edw3nr
      ... be ... dilemma. ... time ... enabled ... Debian ... the ... original ... version to ... would ... else ... retained and ... decision ... Dave, FYI, I use
      Message 2 of 4 , Apr 12, 2006
      • 0 Attachment
        --- In linuxham@yahoogroups.com, w1hkj <w1hkj@...> wrote:
        >
        > Hamish etal,
        >
        > My original intent with the gmfsk mods was to provide a way to
        > conveniently test changes to the application that would eventually
        be
        > incorporated into the mainstream gmfsk source tree. That has not
        > happened. Tomi Manninen, OH2BNS, the author of gmfsk has not been
        > available to discuss the mods. So I am left with an unwanted
        dilemma.
        >
        > I have been considering the issue of whether to change the compile
        time
        > modifications to permanent code changes whose features can be
        enabled
        > and/or modified by configuration dialogs. That would satisfy the
        Debian
        > distribution problem. I think that this would require renaming
        the
        > application since it would not then be as tightly linked to the
        original
        > gmfsk.
        >
        > I know that Ed has been having some problems getting the .48
        version to
        > recognize his hamlib install at compile time. A Debian distro
        would
        > probably help him out of the compile dependency issue. Has anyone
        else
        > experienced similar compile-time problems?
        >
        > I would appreciate hearing from the present users of gmfsk on this
        > idea. What mods do you incorporate? Which ones should be
        retained and
        > which discarded? How difficult do you find the compile time
        decision
        > tree that you need to navigate via the hkj-config.h file
        >
        > Dave (hkj)



        Dave, FYI, I use Debian testing....I had no problems in hkj-config.h
        the only mods I did not use were the Tentec and Kachina mods. My
        biggest problem was tryin to figure out what all was needed to
        compile gmfsk in the first place. I found I was needing several
        libs,dev and others. The one that threw me the most was fftw-dev.

        Ed W3NR
      • Hamish Moffatt
        ... apt-get build-dep gmfsk would pull in all the dependencies of the prepackaged gmfsk, which is probably identical to what s needed by Dave s branch.
        Message 3 of 4 , Apr 12, 2006
        • 0 Attachment
          On Wed, Apr 12, 2006 at 11:14:39AM -0000, edw3nr wrote:
          > Dave, FYI, I use Debian testing....I had no problems in hkj-config.h
          > the only mods I did not use were the Tentec and Kachina mods. My
          > biggest problem was tryin to figure out what all was needed to
          > compile gmfsk in the first place. I found I was needing several
          > libs,dev and others. The one that threw me the most was fftw-dev.

          "apt-get build-dep gmfsk" would pull in all the dependencies of the
          prepackaged gmfsk, which is probably identical to what's needed by
          Dave's branch.

          Hamish
          --
          Hamish Moffatt VK3SB <hamish@...> <hamish@...>
        • Hamish Moffatt
          Hi Dave, ... I have been trying to discuss this with Tomi. I just submitted a cleaned up version of your WANT_WATERFALL_MOD with the interface changes done
          Message 4 of 4 , Apr 14, 2006
          • 0 Attachment
            Hi Dave,

            On Wed, Apr 12, 2006 at 04:51:08AM -0400, w1hkj wrote:
            > My original intent with the gmfsk mods was to provide a way to
            > conveniently test changes to the application that would eventually be
            > incorporated into the mainstream gmfsk source tree. That has not
            > happened. Tomi Manninen, OH2BNS, the author of gmfsk has not been
            > available to discuss the mods. So I am left with an unwanted dilemma.

            I have been trying to discuss this with Tomi. I just submitted a cleaned
            up version of your WANT_WATERFALL_MOD with the interface changes done
            through glade.

            The glade changes are necessary but admittedly not really compatible
            with your approach of compile-time-selectable mods.

            > I have been considering the issue of whether to change the compile time
            > modifications to permanent code changes whose features can be enabled
            > and/or modified by configuration dialogs. That would satisfy the Debian
            > distribution problem. I think that this would require renaming the
            > application since it would not then be as tightly linked to the original
            > gmfsk.

            I think some of the changes make a lot of sense as run-time options,
            like the 1Hz mod, perhaps the ptt mod etc.

            > I know that Ed has been having some problems getting the .48 version to
            > recognize his hamlib install at compile time. A Debian distro would
            > probably help him out of the compile dependency issue. Has anyone else
            > experienced similar compile-time problems?
            >
            > I would appreciate hearing from the present users of gmfsk on this
            > idea. What mods do you incorporate? Which ones should be retained and
            > which discarded? How difficult do you find the compile time decision
            > tree that you need to navigate via the hkj-config.h file

            The latest Debian package (called 0.6+0.7pre1-1) has WANT_WATERFALL_MOD
            functionality.

            Currently I'm grabbing some of your changes into my tree, trying to
            submit them to Tomi, and will also include them in Debian. I don't want
            to get too far out of sync with Tomi though.

            By the way, with WANT_NEW_UI, is the toggle-label access to the
            waterfall mode and zoom necessary? They are already available on the
            context-menu (especially with WANT_WATERFALL_MOD).

            73
            Hamish
            --
            Hamish Moffatt VK3SB <hamish@...> <hamish@...>
          Your message has been successfully submitted and would be delivered to recipients shortly.