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

Re: [linuxham] Re: Compile versus Run Time for gmfsk

Expand Messages
  • 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 1 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 2 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.