Qpid
  1. Qpid
  2. QPID-4499

Relocate all Swig .i files to include directories.

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.20
    • Component/s: C++ Client
    • Labels:
      None

      Description

      Since these files are used for client development, they need to be shipped. Additionally, since swig defaults to looking in the standard include file directories, they should be placed in the same place as other qpid include files; i.e., /usr/include/qpid/ on *nix platforms.

        Activity

        Hide
        Justin Ross added a comment -

        Rejected for 0.20. Allow me to clarify my position.

        I was prepared to accept this for 0.20. Right or wrong, it's by all accounts the dominant convention for similar .i files from other projects, and that's good enough for me. However! It depends on QPID-4207, and that's much too big change to dist metadata for our final release candidate. This will have to wait.

        Show
        Justin Ross added a comment - Rejected for 0.20. Allow me to clarify my position. I was prepared to accept this for 0.20. Right or wrong, it's by all accounts the dominant convention for similar .i files from other projects, and that's good enough for me. However! It depends on QPID-4207 , and that's much too big change to dist metadata for our final release candidate. This will have to wait.
        Hide
        Andrew Stitcher added a comment -

        I disagree with Gordon.

        Generating bindings is a client development activity in my view. With the .i files exported in this way developing bindings is no longer restricted to those with access to the qpid tree, but the only requirement to develop a new client binding is the client include files.

        This strong decoupling is a very good thing from my point of view.

        Obviously you wouldn't export .i files that relate to individual bindings to the include files, but the .i that give the general typemaps that are useful for every binding and point at all the necessary include files seem like very good candidates for export to me.

        Show
        Andrew Stitcher added a comment - I disagree with Gordon. Generating bindings is a client development activity in my view. With the .i files exported in this way developing bindings is no longer restricted to those with access to the qpid tree, but the only requirement to develop a new client binding is the client include files. This strong decoupling is a very good thing from my point of view. Obviously you wouldn't export .i files that relate to individual bindings to the include files, but the .i that give the general typemaps that are useful for every binding and point at all the necessary include files seem like very good candidates for export to me.
        Hide
        Gordon Sim added a comment -

        Personally I find this odd. They are not needed for 'client development' in my view, but for generating the bindings. They are source components of the bindings not installable artefacts of the client library itself.

        Show
        Gordon Sim added a comment - Personally I find this odd. They are not needed for 'client development' in my view, but for generating the bindings. They are source components of the bindings not installable artefacts of the client library itself.
        Hide
        Darryl L. Pierce added a comment -
        Show
        Darryl L. Pierce added a comment - This is committed in r1420320. http://svn.apache.org/viewvc?view=revision&revision=1420320

          People

          • Assignee:
            Darryl L. Pierce
            Reporter:
            Darryl L. Pierce
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development