Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
`redundant build-depends entry` for convenience library with C(++) sources #40
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.
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?
PS: The reason I need separate libraries is that one library builds c (for a
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.
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)
From what I can see, that does match what I'm saying. Concretely, you have