I see in your branch that there is (1) graphics/wxPython-3.0, (2) graphics/wxWidgets-3.0, and (3) python/py-wxpython-3.0. I see that you've set the gnuradio port to try to use (1); I know this will not work, but I'll correct the issue before it is merged; I appreciate your efforts; really.
I have a few questions; please do not take these as critiques; I'm just trying to understand & facilitate discussion: + I see that (3) depends on (1), which is confusing (to me) because (1) is actually installing a version of wxWidgets (that provided with wxPython, such that the versions always match up if the ports' versions are aligned). wxPython is the Python interface to wx, and that's even what the current Portfile for (1) says -- so, if nothing else a correction to the description needs to be made for (1). + Why is the wxPython-included-wxWidgets port named wxPython instead of some variant on wxWidgets? It does not provided wxPython; it provides wxWidgets no matter that the source is from wxPython. That is also what the port "wxWidgets-python" tries to do, with its awkward naming. I'm not saying I have a better naming scheme, but I do not like it being called wxPython if is provides wxWidgets. Which takes me to just having a wxWidgets port (as in the next item) for installing wxWidgets. + Is the version of wxWidgets provided inside the wxPython tarball the same as that found from wxWidgets directly (for the same version)? If so, then why bother with the special port since wxWidgets is already provided elsewhere? Yes, it can result in the current predicament where wxPython has not yet caught up to the wxWidgets API. But, it avoids adding another conflicting or selectable port to those already there. Fewer ports is generally less confusing. That's it for now; keep up the great work! - MLD _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
