only add useful entries for $CPATH, $(LD_)LIBRARY_PATH and $PATH

[bartoldeman]

This avoids adding useless entries in the environment, an
example being GCCcore which adds lib and include which are both
empty apart from subdirectories.

[boegel]

@bartoldeman I don't think there's a need to only do this when there's a single directory being considered?

see ComputeCanada#18

[Flamefire]

This heavily breaks modules!

You usually have a structure like include/libfoo/libfoo.h but include won't be added to CPATH due to it not containing a file, but "only" a folder

Working on a fix...

[bartoldeman]

@Flamefire correct, sorry I missed that. May be simplest to exclude CPATH? The same reasoning does not apply to LIBRARY_PATH/LD_LIBRARY_PATH/PATH.

[Flamefire]

Does it? I think you are right, but I'm not 100% sure. E.g. pkgconfig for a header-only library would be a counter-example.

[Flamefire]

Playing it safe: #3152 removes only folders that have no files recursively

[bartoldeman]

Can you elaborate on pkgconfig @Flamefire ? PKG_CONFIG_PATH is not in the list so I don't understand this.

[bartoldeman]

Now the safe fix defeats the purpose which is to avoid the empty GCCcore directories and similar cases, now they are added again.

[Flamefire]

Ah yes, you are right. Still: Are you 100% sure there is no lib/somefolder/somefile which is used by sometool if lib is in (LD_)LIBRARY_PATH? I'm not.

Can you elaborate on the GCCcore issue? If the folders are really empty, they won't be added. "Empty"=="Do not contain any file and no subdirectory which contains a file" so lib/foo/bar would not be added unless there is a file in bar

[boegel]

I don't understand @bartoldeman's point either, the fix in #3152 (ignoring directories that don't contain any files) makes sense imho...

[bartoldeman]

@Flamefire @boegel With GCCcore we have:

• an empty include with under there c++/8.3.0. You'll never do #include <c++/8.3.0/vector>
• an empty lib (unless you install 32-bit target too), with gcc/x86_64-pc-linux-gnu/8.3.0 under there.
  It's impossible to fix this generically so I merged Only remove folders that contain no files recursively #3152
  Now for GCCcore it's then better to address this in the easyblock. In fact GCCcore doesn't need CPATH and LIBRARY_PATH at all (see Don't set $CPATH and $LIBRARY_PATH anymore for GCC and GCCcore. easybuild-easyblocks#1903 which was merged yesterday)

[bartoldeman]

Actually I should now change the gcc easyblock to remove lib from LD_LIBRARY_PATH for non-32-bit capable gcc (ie. the common case). I'll submit a new PR for that.

[Flamefire]

Ok so there is a file vector in include/c++/8.3.0, did I get this right? Generically you'd want this path added. It is GCC being an exception here because it is the compiler, but for everything else you'd need it. If you don't, you'd need to adapt that in the EasyBlock (or config)

What is the deal with lib? Is there any file in there in 64 bit? If not, my PR is enough, isn't it?