libcudd should be updated to 2.5.0

[ryandesign (Ryan Carsten Schmidt)]

libcudd 2.4.2 is out so the port should probably be updated to that version.

The livecheck should probably also be fixed.

[ryandesign (Ryan Carsten Schmidt)]

Please comment on this update. I spent some time trying to do it now, but when you submitted the port in #16210 you included hundreds of lines of patches, which I'm now struggling to try to understand, and to figure out which parts are still needed and need to be adapted, and which parts should be discarded.

[ryandesign (Ryan Carsten Schmidt)]

Meanwhile, 2.5.0 has been released. Could you supply a patch to update the port please? If you no longer want to be listed as this port's maintainer please let us know.

[SCL@…]

patchfiles

[SCL@…]

I updated the libcudd Portfile to operate with v2.5.0. I omitted the patch concerning the C++ interface because it is unclear why a new interface was needed originally (and whether that reason, if any, still holds for CUDD v2.5.0).

I added attachments to this ticket containing new patchfiles and my patch for the libcudd Portfile.

[ryandesign (Ryan Carsten Schmidt)]

Same comment here as in #41635: there should be a single architecture-independent patch file, not one for each architecture; any 32-bit differences can be dealt with after that (although ideally the same source code would build correctly on any architecture).

[ryandesign (Ryan Carsten Schmidt)]

SCL, sorry, I did not see you were not already Cc'd on this ticket. Please see my remark in the ticket.

[SCL@…]

A new Portfile diff is below. I did not see documentation at ​http://guide.macports.org/ concerning checking word size, so I only check for ppc64 and x86_64. If neither of these is found in ${configure.cc_archflags}, then as suggested, reinplace is used to adjust the patched Makefile.

Note that I am including the diff here rather than attaching it to the ticket to avoid cluttering attachments...until a nearly final version is reached.

--- Portfile.orig	2013-12-04 11:22:41.000000000 -0800
+++ Portfile	2013-12-04 11:22:36.000000000 -0800
@@ -1,10 +1,10 @@
 # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
-# $Id: Portfile 88247 2011-12-23 11:21:32Z ryandesign@macports.org $
+# $Id$
 
 PortSystem          1.0
 
 name                libcudd
-version             2.4.1
+version             2.5.0
 categories          devel
 maintainers         bitchx.it:mij
 description         An efficient library for manipulating decision diagrams
@@ -17,12 +17,19 @@
 homepage            http://vlsi.colorado.edu/~fabio/CUDD/
 master_sites        ftp://vlsi.colorado.edu/pub/
 distname            cudd-${version}
-checksums           sha1 0a0894ff5a2798a73fcacf76d451777aa02919ce
+checksums           sha1 7d0d8b4b03f5c1819fe77a82f3b947421a72d629 \
+                    rmd160 2f7b1dc3118925de268a1f1396ba4e66b65c54e4
 platforms           darwin
 
 # patch to:
 # Makefile: avoid compiler flags that cause errors, add C++ interface target
-patchfiles          patch-Makefile.diff patch-obj-cuddObj.cc.diff patch-obj-cuddObj.hh.diff patch-cudd-Makefile.diff patch-dddmp-Makefile.diff patch-epd-Makefile.diff patch-mtr-Makefile.diff patch-obj-Makefile.diff patch-st-Makefile.diff patch-util-Makefile.diff
+patchfiles          patch-cudd-Makefile.diff patch-dddmp-Makefile.diff patch-epd-Makefile.diff patch-mtr-Makefile.diff patch-obj-Makefile.diff patch-st-Makefile.diff patch-util-Makefile.diff patch-Makefile.diff
+if {![string match "-arch x86_64" ${configure.cc_archflags}]
+    && ![string match "-arch ppc64" ${configure.cc_archflags}]} {
+    post-patch {
+        reinplace "s|-DSIZEOF_VOID_P=8 -DSIZEOF_LONG=8|-malign-double|g" ${worksrcpath}/Makefile
+    }
+}
 
 use_configure       no

[jfilippidis@…]

Cc Me!

[SCL@…]

Should I try to contact the libcudd port maintainer directly (by email)? Given the comment by ryandesign on this ticket 2 months ago, I am also curious whether mij is the libcudd port maintainer.

[ryandesign (Ryan Carsten Schmidt)]

mij is the person listed as this port's maintainer, and he owns this ticket so he has received an email about each comment in this ticket, but he has not responded to this ticket in three years so I fear he has left us. I will try to update the port using your patches. Thanks.

[ryandesign (Ryan Carsten Schmidt)]

Duplicate #42337 provides a new portfile to update the port, but I have not tested it.

[nerdling (Jeremy Lavergne)]

Cc Me!

[rpgoldman]

Cc Me!

[nerdling (Jeremy Lavergne)]

Replying to ryandesign@…: Portfile from #42337 gives me a build failure.

[lockhart (Thomas Lockhart)]

Replying to ryandesign@…:

mij is the person listed as this port's maintainer, and he owns this ticket so he has received an email about each comment in this ticket, but he has not responded to this ticket in three years so I fear he has left us. I will try to update the port using your patches. Thanks.

Hi Ryan. mij is still listed as a maintainer and the update to 2.5.0 seems to have stalled out. What does it need at this point to get restarted? TIA

[lockhart (Thomas Lockhart)]

Slightly updated Portfile including a section for livecheck. Needs patch-Makefile-x86_64.diff renamed to patch-Makefile.diff

[lockhart (Thomas Lockhart)]

Hi all. I've posted a slightly updated Portfile to include a livecheck section. Builds for me. I guess this is waiting on #44781 to make progress, but we're looking forward to it here at JPL. Thanks!

[mf2k (Frank Schima)]

Port abandoned. See #44781.

[jfilippidis@…]

Since libcudd has been abandoned by its original maintainer, and a patch already exists here, can you please update libcudd in the macports repository ? We are waiting for nearly a year now for the libcudd patch submitted above to be applied, so that #41653 can be included in macports. Thanks.

[larryv (Lawrence Velázquez)]

Sorry for the delay. In the future, try posting to macports-dev if a ticket has stalled.

[jfilippidis@…]

Thank you, I did not know - will post in the developers list in the future.

[larryv (Lawrence Velázquez)]

The way the port currently hacks together a dynamic library is not tenable. Since upstream only worries about static libraries, it doesn’t have to concern itself with API compatibility, and the port doesn’t have a maintainer to keep an eye out for this sort of thing.

Since upstream doesn’t provide a dynamic library, the port shouldn’t bother with one. Would anyone care?

[ryandesign (Ryan Carsten Schmidt)]

Since no ports depend on libcudd, removing the dynamic library wouldn't be a problem. If upstream wants to provide one in their build in the future (which would be great) it can come back then.

[jfilippidis@…]

#41653 depends on libcudd and I think that it may depend on the dynamic library, but this needs to be confirmed by its maintainer.

[ryandesign (Ryan Carsten Schmidt)]

All I see in these patches regarding dynamic libraries is adding the flag -dynamiclib, is that correct? I don't see the flag -install_name being added anywhere. Without that, these dynamic libraries can't be used correctly anyway.

[ryandesign (Ryan Carsten Schmidt)]

I still object to patching the Makefile to set SIZEOF_anything. Instead, do that in a header that everything else includes. Set the values based on __LP64__. Off the top of my head (i.e. untested):

#if __LP64__
#  define SIZEOF_LONG 8
#  define SIZEOF_VOID_P 8
#else
#  define SIZEOF_LONG 4
#  define SIZEOF_VOID_P 4
#endif

[ryandesign (Ryan Carsten Schmidt)]

Wait, the dylibs are being made in a post-build block. So why do we have to add -dynamiclib in any Makefile?

[ryandesign (Ryan Carsten Schmidt)]

Larry, are you working on this now or do you want me to see if I can finish it up?

[ryandesign (Ryan Carsten Schmidt)]

I think I'm ready to commit this if you have no objections, Larry.

[larryv (Lawrence Velázquez)]

I was working on removing most of the patches (which are unnecessary if build.args is used judiciously), but you can go ahead and commit, and I’ll clean up afterwards.

[ryandesign (Ryan Carsten Schmidt)]

Ha, I committed right as you commented. r126020

[jfilippidis@…]

Thank you for seeing this through.