redundant build-depends entry for convenience library with C(++) sources

[OlivierSohn]

Hello,

I recently came across this corner case: in this cabal file, there is a ("main") library, and a convenience library which just builds C++ sources.

The main library declares the convenience library as a dependance, so that the c++ objects built by the convenience library are available at link time for projects that depend on the main library.

If I remove this dependency, the main library builds, but the projects that depend on this main library have "symbol not found" link errors.

weeder detects the convenience library as a redundant build-depends entry of the main library.

In a way, I think this is a bug, and weeder should consider that dependencies on convenience libraries building C / C++ sources are never redundant (considering that here the semantics of the dependency is "aggregate build results").

What do you think?

Thanks!

PS: The reason I need separate libraries is that one library builds c (for a .hsc file), the other builds c++, and build options are not compatible (and cxx-sources / cxx-options is not yet available in the version of cabal used!).

[ndmitchell]

My inclination is to say you should use weeders ignore feature here. I could say that any library that links to C is not eligible for being detected as redundant, but I can only do that within a package file (you don't know if you are depending on bytestring just for its C functions), and it's a bit of a special case. Furthermore, people should generally declare and wrap their C functions in one package, so as the C interface doesn't leak too far.

I can understand that it's the right thing in this case, but usually it isn't.

[OlivierSohn]

Yes it makes sense. I'll use the ignore feature! Thanks.

[ndmitchell]

Thanks, I added it as a false positive in 18e8639 so the knowledge isn't lost.

[OlivierSohn]

While reading the false positive commit, and re-reading your previous message I see that maybe there is a misunderstanding: The C functions are not used directly by the other packages, they are called only from the library of the same package. But at link-time, the executable in the other package needs the objects corresponding to the C-functions. (in a way we can say that the other project uses the compiled binary object of the function "at link time", because a library it depends on uses it, but it doesn't use it directly)

[ndmitchell]

Indeed, I'm confused. Can you tell me the actual weeder error, so I have the names of what it is saying is redundant where?

[OlivierSohn]

Yes, the corresponding .weeder.yaml file is here. This is the relevant part:

- package:
  - name: imj-audio
  - section:
    - name: library
    - message:
      - name: Redundant build-depends entry
      - depends: imj-audio-cxx

[ndmitchell]

From what I can see, that does match what I'm saying. Concretely, you have imj-audio-cxx which provides C functions, which aren't called by Haskell functions in imj-audio-cxx (because that library doesn't have any Haskell code in it), but are presumably called directly by the imj-audio library? That corresponds to a library providing C functions which are used directly from another library. Where have I gone wrong? (Ignoring the C vs C++ difference, and just using C to refer to either.)

[OlivierSohn]

You're right, I misinterpreted: when you wrote library, I was thinking "main library" (i.e imj-audio here) but in fact library referred to the convenience library (imj-audio-cxx).

Sorry for the noise :)

[ndmitchell]

No problem - I appreciate the report, and the subsequent clarifications - I certainly learnt something, and I think we've distilled a nice case where Weeder is wrong.

[OlivierSohn]

And I've learned about the ignore feature, I'm almost ready to use weeder in my CI script now :)