I've added the quotes.

PS. I've clicked something so that the review requests were generated, you can ignore them.

I wonder if some other environment variables are there that make CMake and AutoTools look more closely at a changed --prefix path when searching for the required dependencies? CMake can have some I suppose.

@vladdoster in commit b1da9b2 I've added support for $ZPFX also to:

• CMake (add $ZPFX to $CMAKE_PREFIX_PATH),
• Autotools (add a $ZPFX/share/config.site file which sets up CPP…/LDFLAGS but only (useful feature) if --prefix is pointing to $ZPFX)
• $LD_LIBRARY_PATH to include $ZPFX/lib so that libraries are found when running a program.

The first two changes make CMake and Autotools find libraries installed in ZPFX.

Also, an extra hunk in the commit – typeset -gU PATH path – make $PATH unique.

@vladdoster: Chances to merge?

I've resolved conflicts.

Hey could the PR be merged? It is a simple change to make libraries found.

When will it be merged, @vladdoster ?

@psprint,

The make and configure ices don't really work currently, IIRC.

Using $ZPFX as the prefix (i.e., ./configure --prefix=$ZPFX or make PREFIX=$ZPFX makes command not work correctly:

zi delete <program>

Example

The following is cleaned up correctly:

zi delete shc --yes
zi for \
    null \
    id-as \
    lman \
    lbin'!bin/shc' \
    configure"--prefix=$ZI[PLUGINS_DIR]/shc" \
    make"PREFIX=$ZI[PLUGINS_DIR]/shc install" \
  @neurobin/shc

The following is not cleaned up and seems to install man page in wrong place:

zi delete shc --yes
zi for \
    null \
    id-as \
    lman \
    lbin'!$ZPFX/bin/shc' \
    configure"--prefix=$ZPFX" \
    make"PREFIX=$ZPFX install" \
  @neurobin/shc

Am I missing something?

@vladdoster When you set prefix to the dir of the plugin then it's natural that its files get cleaned up when deleting the plugin. To obtain similar effect zi delete could detect uninstall target in Makefile and run it before deleting plugin dir (that contain the Makefile, but not plugin installed files).

@vladdoster I can see that you like to install to $PWD (plugin dir) instead of $ZPFX. That's an interesting approach that has to be yet better recognized. For example libraries when installed to PWD will not be found, unless a way of adding the local directories in PWD to some variables (don't know which) will be found. I can however see the approach working for some single-binary programs like bat, fd. For now, I'll add make uninstall to zi delete to make $ZPFX installations more clean.

@vladdoster I've switched from tying with -T to a regular [[ $var != *$ZPFX* ]] check (little more sophisticated in the source), no -U flags is being set and no stray array vars like pkg_cfg are left over.

@vladdoster Here's info on config.site, it's a cool mechanism that makes libraries and includes found https://www.paxswill.com/autotools-trick-config-dot-site/

@vladdoster: I added in #468 make uninstall run to zinit delete … command. Basically, if the uninstall target is there in the Makefile of the removed plugin/snippet, it'll be run as: make -C {plugin/snippet dir} uninstall before removing the dir.

@vladdoster come on, could the PR be merged quicker?

I've found a bug – CMake var should use ; not : to separate dirs. Could the PR be merged?

@vladdoster See documentation of CMAKE_PREFIX_PATH: https://cmake.org/cmake/help/latest/variable/CMAKE_PREFIX_PATH.html#variable:CMAKE_PREFIX_PATH

It is perfect for what is needed to make $ZPFSX more discoverable.

@psprint,

I'm not purposefully ignoring your PRs. There are failing checks that need to be resolved (i.e., commit message). It is how the CHANGELOG is generated and makes it easier to decipher commits when searching through the git log.

It clearly states what the issues are.

I opened an empty PR which passes the linter. Feel free to use it and amend your commit messages.

OK, thanks for pointing where to look for info, I've made the commit message pass linter.

Ping?

@psprint,

I'm not purposefully ignoring your PRs. There are failing checks that need to be resolved (i.e., commit message). It is how the CHANGELOG is generated and makes it easier to decipher commits when searching through the git log.

@psprint,

Please see my previous comment.

@vladdoster the problem is that the unit tests are failing randomly and that I cannot use docker on my PCLInuxOS to generate documentation. You've once wrote that the documentation isn't a problem …

@vladdoster: It buggs me that one still cannot compile with deps from $ZPFX. The unit test failures are accident, not related to the changes. So after generating zshelldoc docs one could merge the PR?

@vladdoster: I've found one other bug (: instead of ;) and fixed it. The code is now without any errors, could it be merged? It opens $ZPFX installed libs to new software installed via zinit.

What about this PR? It is important.

ping :) The unit test failure is some random one:

__zunit_tmp_test_function:17: exec format error: /Users/runner/work/zinit/zinit/tests/_support/tmp.TlWR1eUBGc/polaris/bin/git-mkver