add ogdf

[hadim]

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
• License file is packaged (see here for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• If static libraries are linked in, the license of the static library is packaged.
• Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/ogdf) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipes/ogdf:

• Recipe with the same name exists in bioconda: please discuss with @conda-forge/bioconda-recipes.

[hadim]

Context and history about that package at #12498 (comment)

[hadim]

@conda-forge/help-c-cpp, please review. The OSX error seems to be due to lower/uppercase mismatch in CMake (everything works fine on Linux). I tried a few things without success. If nobody has an idea, I'll simply disable osx before merging.

[hadim]

@N-Coder: are you interested in being a maintainer?

[N-Coder]

Maybe it would make the patch file easier to maintain (GitHub doesn't even want to display it online due to its size) if you only put actual changes to files' contents into the diff and then delete the respective folders in the script?

[carterbox]

I agree. Please only include the changes to the CMake files in this diff, and do the file deletions in the build script. Otherwise, the patch seems to be 99% file deletion.

[N-Coder]

Hey, here are some notes from my side...

• OGDF grew a PyPi package in the meantime (which is also about to become part of the official distribution), so it would probably be a good idea to keep the conda version tightly in sync with that, otherwise I see people getting problems because they installed the inofficial conda version that is somehow different than the official PyPi version.
• The PyPi version has a few difference in how OGDF is built, see here for the cmake flags and the fix for generating portable builds.
• Furthermore, the PyPi version will probably switch to a debug build (possibly also including things like asan) soon because that makes building things with its python interface a lot easier. This probably conflicts with the efficiency oriented use-case of tmap (in which I still would recommend static linkage with the OGDF, but that seems to be a problem with conda -- have you thought about publishing a PyPi package to a wider audience instead of being restricted to the conda-forge ecosystem? On PyPi, you could simply distribute a statically linked version of the OGDF within tmap and everything would be fine and even faster), so we'd probably need to find a way how to support both usages next to each other.
• Did you try running this build of the OGDF? IIRC the packaged version of COIN was somewhat old because there were unannounced breaking changes at runtime in a COIN release along the way, which led to the OGDF vendoring a working version. So it might be that the COIN part is actually not working with this build (same possibly with pugixml). Maybe running these smoke tests on some graph loaded from an (xml-based) graphml file would provide some first insights into this (although also no guarantee that everything actually works).
• I'm not super happy with having a redundant coda-forge version of the OGDF wheel as that is also available on PyPi to a superset of conda-forge's userbase. So you can keep me in the loop if you insist on pushing this to conda-forge, but I don't see me or other OGDF devs investing further resources into conda-forge that could be put to better use by working on the PyPi release or the library itself.

[carterbox]

I agree. Please only include the changes to the CMake files in this diff, and do the file deletions in the build script. Otherwise, the patch seems to be 99% file deletion.

[carterbox]

Please add an existence check for at least one file of each of the following categories: Cmake Config, Header,

[carterbox]

Please address static/underlinking warnings. We do not allow static linking.

https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=661341&view=logs&j=6f142865-96c3-535c-b7ea-873d86b887bd&t=22b0682d-ab9e-55d7-9c79-49f3c3ba4823&l=3106

[carterbox]

Looks like the errors on CMake for OSX are some combination of needing to provide CMake some better search paths, ogdf find_library implementations not working correctly for OSX, and/or the upstream packages not exporting the same CMake targets on all platforms.

[carterbox]

Add the --target option here and only build OGDF (the tests and example targets are unused).

[hadim]

I don't think I'll have time to maintain that repo. Someone should take the lead.

[N-Coder]

If you need any help bringing a pre-built tmap package (i.e. wheel) to PyPI feel free to contact me. Doing that for the OGDF was pretty easy and anything that is available via pip is also available to users of conda (but not the other way around), so I don't really see a big need to invest too much work into abiding to the rules that are imposed on conda-forge.

[hadim]

If you need any help bringing a pre-built tmap package (i.e. wheel) to PyPI feel free to contact me. Doing that for the OGDF was pretty easy and anything that is available via pip is also available to users of conda (but not the other way around), so I don't really see a big need to invest too much work into abiding to the rules that are imposed on conda-forge.

Conda forge has a lot of advantages compared to built binaries on PyPI. I just don't have the time to work on it, but ultimately, OGDF should be packaged on conda-forge.

Thank you for your proposal on the TMAP wheel, but we already have an internal TMAP conda package that suits our needs for the moment.