cloog depends on isl but cloog and isl conflict

[ryandesign (Ryan Carsten Schmidt)]

--->  Computing dependencies for isl
--->  Fetching distfiles for isl
--->  Attempting to fetch isl-0.07.tar.bz2 from http://distfiles.macports.org/isl
--->  Verifying checksum(s) for isl
--->  Extracting isl
--->  Applying patches to isl
--->  Configuring isl
--->  Building isl
--->  Staging isl into destroot
--->  Installing isl @0.07_0+universal
--->  Activating isl @0.07_0+universal
Error: org.macports.activate for port isl returned: Image error: /opt/local/include/isl/aff.h is being used by the active cloog port.  Please deactivate this port first, or use 'port -f activate isl' to force the activation.
Please see the log file for port isl for details:
    /opt/local/var/macports/logs/_Users_rschmidt_macports_dports_devel_isl/isl/main.log

$ port installed cloog isl
The following ports are currently installed:
  cloog @0.16.3_1+universal (active)
  isl @0.07_0+universal

[adfernandes (Andrew Fernandes)]

Hmm... I actually don't know how to fix this, other than the port -f activate isl thing. Of course, that's not good for smooth port updating.

Is there a "MacPorts" way of fixing this?

[pixilla (Bradley Giesbrecht)]

Cloog currently has headers in include/isl. Cloog currently installs SOME headers to include/cloog/isl. Can cloog be configured to install ALL it's include/isl headers under include/cloog/isl?

$ port -q contents cloog | sed 's,[^/]*$,,' | sort -u
  /opt/local/bin/
  /opt/local/include/cloog/
  /opt/local/include/cloog/isl/
  /opt/local/include/cloog/matrix/
  /opt/local/include/isl/
  /opt/local/lib/
  /opt/local/lib/pkgconfig/

Or if the isl headers the cloog port is installing are the same headers the isl port provides then the cloog port could remove include/isl in post-destroot.

Caveat: I have no experience with cloog or isl.

[pixilla (Bradley Giesbrecht)]

Wishing again for comment editing :)

[ryandesign (Ryan Carsten Schmidt)]

That's not all. cloog also currently installs libisl.dylib, isl.pc, and other files the isl port installs.

$ port contents cloog | grep isl
  /opt/local/include/cloog/isl/backend.h
  /opt/local/include/cloog/isl/cloog.h
  /opt/local/include/cloog/isl/constraintset.h
  /opt/local/include/cloog/isl/domain.h
  /opt/local/include/isl/aff.h
  /opt/local/include/isl/aff_type.h
  /opt/local/include/isl/arg.h
  /opt/local/include/isl/band.h
  /opt/local/include/isl/blk.h
  /opt/local/include/isl/config.h
  /opt/local/include/isl/constraint.h
  /opt/local/include/isl/ctx.h
  /opt/local/include/isl/dim.h
  /opt/local/include/isl/div.h
  /opt/local/include/isl/flow.h
  /opt/local/include/isl/hash.h
  /opt/local/include/isl/ilp.h
  /opt/local/include/isl/int.h
  /opt/local/include/isl/list.h
  /opt/local/include/isl/local_space.h
  /opt/local/include/isl/lp.h
  /opt/local/include/isl/map.h
  /opt/local/include/isl/map_type.h
  /opt/local/include/isl/mat.h
  /opt/local/include/isl/obj.h
  /opt/local/include/isl/options.h
  /opt/local/include/isl/point.h
  /opt/local/include/isl/polynomial.h
  /opt/local/include/isl/printer.h
  /opt/local/include/isl/schedule.h
  /opt/local/include/isl/seq.h
  /opt/local/include/isl/set.h
  /opt/local/include/isl/set_type.h
  /opt/local/include/isl/stdint.h
  /opt/local/include/isl/stream.h
  /opt/local/include/isl/union_map.h
  /opt/local/include/isl/union_set.h
  /opt/local/include/isl/vec.h
  /opt/local/include/isl/version.h
  /opt/local/include/isl/vertices.h
  /opt/local/lib/libcloog-isl.2.dylib
  /opt/local/lib/libcloog-isl.a
  /opt/local/lib/libcloog-isl.dylib
  /opt/local/lib/libcloog-isl.la
  /opt/local/lib/libisl.7.dylib
  /opt/local/lib/libisl.a
  /opt/local/lib/libisl.dylib
  /opt/local/lib/libisl.la
  /opt/local/lib/pkgconfig/cloog-isl.pc
  /opt/local/lib/pkgconfig/isl.pc

So maintainers: what's up with that? Either cloog should depend on the isl port and not install the isl files itself, or cloog should install the isl files itself, and not depend on isl, and the two ports should declare that they conflict with one another. What's it to be?

[adfernandes (Andrew Fernandes)]

Uhh... mcalhoun - any idea what to do about this? For me, a one-time port -f fixed the dependency.

The problem is that cloog can be built using an internal isl (which it then installs) or the "system" isl, on which it will then depend.

Pre r92992 has cloog using and installing its own internal isl. r92992 and later has it use the system isl. However, the dependent isl can't be installed because the current cloog (the one being upgraded) has its own isl.

Nope - no surprise to me why gcc's graphite is not enabled by default.

So... is there a way to automate this sort of dependency loop?

[ryandesign (Ryan Carsten Schmidt)]

Forcing the activation doesn't fix anything, it just overwrites one port's files with another's, which is seldom a good thing to do.

To be clear: my currently-installed cloog @0.16.3_1+universal is not being shown as outdated. If the intention is that cloog should depend on and use the isl port's files, then that is not currently happening, and a fix in the cloog port is needed.

Yes, you can automate the unusual occurrence where files that were provided by a previous version of a port are now provided by a dependency. If there were a new revision/version of cloog that used isl's files and did not itself install the isl files, then the isl port would need to be modified to deactivate the existing cloog port to allow the upgrade to occur smoothly. We call this the "deactivate hack" and it's been used in several ports before. See the pre-activate block in the simutrans-pak64 subport of the simutrans Portfile for an example.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to ryandesign@…:

Forcing the activation doesn't fix anything, it just overwrites one port's files with another's, which is seldom a good thing to do.

To be clear: my currently-installed cloog @0.16.3_1+universal is not being shown as outdated. If the intention is that cloog should depend on and use the isl port's files, then that is not currently happening, and a fix in the cloog port is needed.

Yes, you can automate the unusual occurrence where files that were provided by a previous version of a port are now provided by a dependency. If there were a new revision/version of cloog that used isl's files and did not itself install the isl files, then the isl port would need to be modified to deactivate the existing cloog port to allow the upgrade to occur smoothly. We call this the "deactivate hack" and it's been used in several ports before. See the pre-activate block in the simutrans-pak64 subport of the simutrans Portfile for an example.

Certainly, you are correct in noting the dangers "port -f".
On my machine, it was never necessary.
The entire point of

configure.args-append \
                     --with-isl=system

in r92992 was to prevent cloog from installing isl.
For me, cloog installs the following:

$ port contents cloog | grep isl
  /opt/local/include/cloog/isl/backend.h
  /opt/local/include/cloog/isl/cloog.h
  /opt/local/include/cloog/isl/constraintset.h
  /opt/local/include/cloog/isl/domain.h
  /opt/local/lib/libcloog-isl.2.dylib
  /opt/local/lib/libcloog-isl.a
  /opt/local/lib/libcloog-isl.dylib
  /opt/local/lib/libcloog-isl.la
  /opt/local/lib/pkgconfig/cloog-isl.pc

I am a little unsure why cloog is not listed as outdated.
Wouldn't increasing the epoch in r92997 indicate the need for an upgrade?

Once we get MacPorts to recognize that cloog is out of date, then we may still be left with the problem that:

• cloog can't upgrade until isl is installed
• isl can't be installed until cloog is upgraded

The "deactivate hack" would then seem the way to go.

I will submit a patch this weekend.

[ecronin (Eric Cronin)]

When I asked about this on -dev a while back the answer was that 0.16.3_0 epoch 0 and 0.16.3_0 epoch 1 are assumed to have identical contents, and that it is intentional that they won't show as outdated:

​http://old.nabble.com/Re%3A--91865--trunk-dports-science-netcdf-cxx-Portfile-p33679541.html:

It doesn't matter, by definition. A higher epoch just tells you that an older-looking (but different) version is actually newer. If name,version,revision,variants are all the same, it's the same software.

This means you can upgrade a port from 1.0 to 1.1, and then if there are problems with 1.1, revert to 1.0 by increasing the epoch, and nobody who hadn't upgraded yet has to rebuild.

So you need to update to a revision that's never been used before for port to think the epoch 1 version is newer...

I still think this is very confusing behavior, but I don't have the statistics on how many times epoch is upped and a pure revert happens vs the Portfiles not being identical for the same version between epochs.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Did r93462 and r93463 fix the problem?

[ryandesign (Ryan Carsten Schmidt)]

Angelo Graziosi sent me a transcript of his experince:

$ sudo port outdated
The following installed ports are outdated:
cloog                          0.16.3_1 < 0.16.3_2

$ sudo port upgrade cloog
--->  Computing dependencies for isl
--->  Fetching archive for isl
--->  Attempting to fetch isl-0.07_1.darwin_11.x86_64.tbz2 from http://packages.macports.org/isl
--->  Attempting to fetch isl-0.07_1.darwin_11.x86_64.tbz2.rmd160 from http://packages.macports.org/isl
--->  Installing isl @0.07_1
--->  Deactivating cloog @0.16.3_1
--->  Unable to deactivate cloog @0.16.3_1, the following ports depend on it:
--->  	gcc46 @4.6.3_2
--->  	gcc47 @4.7.0_3
Error: org.macports.activate for port isl returned: Please uninstall the ports that depend on cloog first.
Please see the log file for port isl for details:

/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_isl/isl/main.log
Error: Problem while installing isl

So I don't think we are completely solved yet.

[su-v]

Cc Me!

[su-v]

Replying to ryandesign@…:

So I don't think we are completely solved yet.

Confirmed on OS X 10.7.4, Xcode 4.3.2: cloog fails to upgrade due to conflict with isl

$ port outdated
The following installed ports are outdated:
clang-3.1                      3.1-r155781_1 < 3.1_1  (epoch 0 < 1)  
clang-3.2                      3.2-r155781_1 < 3.2-r157234_1   
cloog                          0.16.3_1 < 0.16.3_2       
dragonegg-3.1                  3.1-r155781_0 < 3.1_0  (epoch 0 < 1)  
dragonegg-3.2                  3.2-r155781_0 < 3.2-r157234_0   
llvm-3.1                       3.1-r155781_0 < 3.1_0  (epoch 0 < 1)  
llvm-3.2                       3.2-r155781_0 < 3.2-r157234_0   
$ port upgrade outdated
<snip>
--->  Cleaning clang-3.2
--->  Computing dependencies for isl
--->  Fetching distfiles for isl
--->  Attempting to fetch isl-0.07.tar.bz2 from http://lil.fr.distfiles.macports.org/isl
--->  Verifying checksum(s) for isl
--->  Extracting isl
--->  Applying patches to isl
--->  Configuring isl
--->  Building isl
--->  Staging isl into destroot
--->  Installing isl @0.07_1
--->  Deactivating cloog @0.16.3_1
--->  Unable to deactivate cloog @0.16.3_1, the following ports depend on it:
--->  	gcc46 @4.6.3_2
--->  	gcc47 @4.7.0_3
Error: org.macports.activate for port isl returned: Please uninstall the ports that depend on cloog first.
Please see the log file for port isl for details:
    <snip>
Error: Problem while installing isl
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets

$ port installed cloog isl
The following ports are currently installed:
  cloog @0.16.3_1 (active)
  isl @0.07_1

[ Note: port installs from source due to custom ${prefix} ]

[adfernandes (Andrew Fernandes)]

Hmm... I just did a full sync and upgrade, and MacPorts reports the following:

The following installed ports are outdated:
isl                            0.07_0 < 0.07_1           

It does not matter how many times I port upgrade, the isl port is still outdated.

Then I noticed this:

The following ports are currently installed:
  isl @0.07_0 (active)
  isl @0.07_1

Activating isl @0.07_1 did not require -f, so I'm guessing the "install/activate" hack is not quite complete.

Very odd... it installed isl @0.07_1 but did not activate it.

Hope this provides useful clues.

[ryandesign (Ryan Carsten Schmidt)]

I don't think that provides any clues. I think we already have the clues: the deactivate hack doesn't work in its present form when the port we're trying to deactivate has other ports that depend on it (i.e. gcc47 gcc46). We need to figure out if we can basically add the force flag to the deactivate hack.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I am hoping that r93579 fixes the problem.
Can someone please confirm.

[larryv (Lawrence Velázquez)]

Cc Me!

[larryv (Lawrence Velázquez)]

Replying to mcalhoun@…:

I am hoping that r93579 fixes the problem.
Can someone please confirm.

When I upgraded to isl @0.07_2, cloog @0.16.3_2 was deactivated without issue. Then rev-upgrade saw thatgcc46 and gcc47 were broken and reactivated cloog.

[su-v]

Replying to mcalhoun@…:

I am hoping that r93579 fixes the problem.
Can someone please confirm.

After a selfupdate, port upgrade outdated succeeded - on OS X 10.7.4, Xcode 4.3.2, MacPorts 2.1.1 (for details, see attached console log).

[ Note: revupgrade_mode is set to report only. ]

[larryv (Lawrence Velázquez)]

Cc Me!

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Between r93462 , r93579, and r96994, I believe this issue was fixed already but the ticket never closed.