[darknet] Update to some commit from hank-ai
Resolves #46384.
Upstream:
- New repo is listed in old repo's README.
- OpenCV is mandatory.
- Hardcoded dynamic linkage.
- No CMake config.
- android: broken due to lack of backtrace.
- uwp: broken due to lack of _popen.
- No curated "release" commits, only branches.
Port:
- Simplified feature list.
- Drops unused vendored getopt.
@stephanecharette Shouldn't we restore static linkage and exported CMake config?
The port used to offer
darknet provides CMake targets:
# this is heuristically generated, and may not be correct
find_package(Darknet CONFIG REQUIRED)
target_link_libraries(main PRIVATE Darknet::dark)
Personally I recommend to use the same word and spelling everywhere, unlike Darknet::dark.
Note that v5.1 is a development branch. It is not released. I suggest using the branch named master which has the latest v5.0 release.
Hm, I have no problem accepting that 5.1 is a development branch when we talk about git branches.
But by only looking at GH, I don't see any recent GH release.
And I don't see any hint that git tag 5.1 is less mature than git tag 5.0. What is the purpose of tag 5.1?
The master branch is what has been released.
I work on branches, like 4.1 and 5.1, and once ready I merge into master.
This is why the readme instructions are for master and not for the development branch.
5.0 is not newer than 5.1. But 5.1 is not released yet.
But 5.1 is not released yet.
Then there shouldn't be a 5.1 tag at all.
Then there shouldn't be a 5.1 tag at all.
I'm sorry you feel that way. :( I don't know why you're telling us we shouldn't create tags. The current development branch is version 5.1. Thus, it is tagged 5.1. That's all there is to it.
I don't know why you're telling us we shouldn't create tags.
This is not what I am saying. I don't object to the use of tags and branches at all.
I do object to the use of (public) tags to give names to moving heads. This is exactly what branches exist for. In particular, I do object to using the same name for a tag and a branch.
But of course it is up to you stick to your pattern even if it is not very common.
can you please create a different darknet-hank-ai port? the fork maintained by @stephanecharette, while accepted as legit a long time ago upstream, is very different from the original darknet and I'd say it should deserve another name
can you please create a different darknet-hank-ai port? the fork maintained by @stephanecharette, while accepted as legit a long time ago upstream, is very different from the original darknet and I'd say it should deserve another name
Is there an advantage to keep the old Darknet fork in vcpkg and rename the new version as something different? All we'll end up doing is confusing users if we now decide to rename Darknet to something else when installed via vcpkg. People will use vcpkg to install "darknet" but they're going to get the old code, not the modern one.
I disagree that the fork I maintain is somehow "very different". It uses the exact same config files, the exact same weights, the format of everything is exactly the same. It is not 2 different products, it is the modern maintained version of the original Darknet codebase originally written by Joseph.
Even when giving the new source a different port different name, the old darknet port would need to be delisted (or to point to new name) when both sources provide the same names (files, symbols). With delisting, I'm not convinced there is much value left in using a different name.
A switch in version scheme would help signal the advances. But given the previous discussion, we will probably have to stick to version-date.
It uses the exact same config files, the exact same weights, the format of everything is exactly the same. It is not 2 different products, it is the modern maintained version of the original Darknet codebase originally written by Joseph.
It should be noted that the purpose of vcpkg is providing libraries, not executables. For libraries, the most relevant difference is changes in API.
I think this PR is complete. Leaving a few days for your comments before marking it ready-for-review.
the two frameworks are totally different and incompatible. That's why i was asking for two different port names. Just one example: darknet is in C, this new one is in C++. Having the same input/output does not make them compatible in the same project without modifications. And the code in the original repository is still perfectly fine, just barely maintained (if you don't trust these words just check the commits in the alexey's port, or the daily github massive actions runs that happen - something not covering this new "maintained port"). Each port can live in a specific include folder or have a specific library name without much hassle, i don't see the problem. In any case, it is up to the community decision and it will be perfectly accepted, this is just my personal opinion
are totally different and incompatible ... darknet is in C, this new one is in C++
All of those statements are false. I kept the exact same C API that Darknet has always had. See "darknet.h" in my repo vs "darknet.hpp". I did add a new C++ interface, but the library still has the same C API. Large parts of the code is now re-written in C++ to get some optimizations that aren't possible in C (such as references) but the darknet.so library and the C API are still there.
I have no idea if this matters, but I did have AlexeyAB's prior permission to create the fork that I maintain when he abandoned his own fork. I can provide the e-mail if necessary. AlexeyAB now works for Apple which is why his old fork of Darknet had to be abandoned.
At least the removal of CMake config is unfortunate. I wish I found some time to make a small test port.