File collisions on AFNI install

[TheChymera]

As discussed at the AFNI training event in Hanover, I've been trying to package AFNI. Based on @leej3 's work and a bit of my own, it now seems to build fine, even using a number of system libraries instead of bundling its own. However, at the end I get some file collisions.

This is the full build log → https://ppb.chymera.eu/2fee0a.log
And this is the snippet listing the collisions and what packages the already present files belong to (included at the end of the above log):

 * Detected file collision(s):
 *
 * 	/usr/bin/mpeg_encode
 * 	/usr/bin/whirlgif
 * 	/usr/lib64/libf2c.so
 *
 * Searching all installed packages for file collisions...
 *
 * Press Ctrl-C to Stop
 *
 * dev-libs/libf2c-20130927-r1:0::gentoo
 * 	/usr/lib64/libf2c.so
 *
 * sci-biology/fsl-6.0.4:0::science
 * 	/usr/bin/whirlgif
 *
 * media-video/mpeg-tools-1.5b-r5:0::gentoo
 * 	/usr/bin/mpeg_encode

Do you know whether:

These are indeed the same files which are provided by those other listed packages? I am particularly wondering about /usr/bin/whirlgif — could it be AFNI and FSL are providing the same file?

If so:

1. Could these files be dropped safely without compromising AFNI function, and instead be provided by those other packages by listing them as runtime dependencies? Again this seems really weird with respect to whirlgif and FSL — seems weird that AFNI would depend on FSL
2. Is there any way to specify in the build system that these are already present if they are to be compile-time dependencies instead? I am able to use e.g. -DUSE_SYSTEM_GTS=ON, but I see no such options for MPEG or libf2c.

If not:

3. Is it safe to rename them with sed in the source code without compromising AFNI function?

[TheChymera]

This is the branch from which I'm building → https://github.com/TheChymera/afni/tree/packaging
With a draft PR for the time being → #560

[afni-rickr]

It was great to meet you in Hanover!

It seems that the cmake build is a little different than the make build. We do not distribute mpeg_encode. If that is done in cmake, it could be turned off.

But both whirlgif and libf2c.so are indeed being distributed.
Since whirlgif is a non-AFNI executable, it is certainly not necessary to distribute if it already exists. It isn't a needed file in any case, but is nice to have.

libf2c.so is probably important to distribute, because f2c is not run as part of the build. Those C files were made years ago now, based on the f2c version that is shipped. So while an external library might work fine, it also might not. It depends on how version-specific the code is in the converted C files. Our distributed binaries will look for the locally distributed library. I am not sure what cmake does with this.

Thanks!

[TheChymera]

We do not distribute mpeg_encode. If that is done in cmake, it could be turned off.

Do you know how I could do this? I couldn't find any sort of mpeg USE_SYSTEM_* option in CMake :(

Since whirlgif is a non-AFNI executable, it is certainly not necessary to distribute if it already exists. It isn't a needed file in any case, but is nice to have.

So it's not dynamically linked to by any other AFNI files, and I can drop it with the only consequence being that it itself is missing? What does it do by the way?

libf2c.so is probably important to distribute, because f2c is not run as part of the build.

Can I stop it from being built at all? I mean I could just skip installing it, but why spend the time to build it then :)

[TheChymera]

@afni-rickr thank you for the tips here, the package now builds without file conflicts 💛.
This is the full build log: https://ppb.chymera.eu/d5cabb.log

Could you confirm that with the exception of whirlgif all required files are present? This is the file list I now have for the installed package: https://ppb.chymera.eu/2abb58

I notice there is only one .py file. I think there should be more. Going by our in-person discussion I remember you saying that the Python things are just scripts and AFNI does not distribute a Python package. The build system has a -DCOMP_PYTHON=ON option, which, if I enable I get ModuleNotFoundError: No module named 'setuptools' which I assume means CMake is trying to build some python package (full build log with that option turned on, here → https://ppb.chymera.eu/c510ac.log).