Avoid unbound variables in activation scripts

[chrisburr]

Looks like this was already noticed in #82 so I won't explain 😄

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[chrisburr]

@conda-forge-admin, please rerender

[chrisburr]

From conda-forge/libxslt-feedstock#36 I don't understand why this isn't being done with compile time flags instead? (In fact it looks like it should already be doing)

The PR description mentions:

Compile-time defaults cannot be used, because the value of XML_CATALOG_FILES will depend on the name of the environment where it is installed.

but that should be handled by conda's prefix replacement? @hattne can you clarify?

[hattne]

From conda-forge/libxslt-feedstock#36 I don't understand why this isn't being done with compile time flags instead? (In fact it looks like it should already be doing)

The PR description mentions:

Compile-time defaults cannot be used, because the value of XML_CATALOG_FILES will depend on the name of the environment where it is installed.

but that should be handled by conda's prefix replacement? @hattne can you clarify?

The default catalog path in the libxml2 sources is derived from SYSCONFDIR, which is determined at compile time. Unless the root of the build environment is identical to the root of the environment at runtime (and SYSCONFDIR is the same in both environments), the built-in catalog path will be not work. As far as I can see, there is no reasonable way conda's prefix replacement could handle arbitrary hardcoded strings compiled into a binary.

[chrisburr]

As far as I can see, there is no reasonable way conda's prefix replacement could handle arbitrary hardcoded strings compiled into a binary.

Unless I've misunderstood this is exactly what conda's prefix replacement should do. Conda-build uses a very long install prefix so that at install time conda can replace $LONG_PREFIX/something{NULL BYTE} with $INSTALL_PREFIX/something{NULL BYTE plus extra null byte padding if needed}.

[hattne]

As far as I can see, there is no reasonable way conda's prefix replacement could handle arbitrary hardcoded strings compiled into a binary.

Unless I've misunderstood this is exactly what conda's prefix replacement should do. Conda-build uses a very long install prefix so that at install time conda can replace $LONG_PREFIX/something{NULL BYTE} with $INSTALL_PREFIX/something{NULL BYTE plus extra null byte padding if needed}.

I stand corrected: I did not understand the full extent of conda prefix replacement (I am, however, still unconvinced it is reasonable). Better figure out why it was not working in the first place…

[hattne]

Windows does need a fix, because there SYCONFDIR is not set; I'll come up with some kind of patch for that. As to what went wrong on Unix, I cannot say: at this stage my best guess is that I was inadvertently running xsltproc from the host operating system rather than the one from conda.

[hattne]

I did actually write patch to set SYSCONFDIR on Windows but it's useless in this context, because it appears prefix-replacement in binaries is done differently on Windows. As noted by @chrisburr, this PR is not necessary on Unix, but it may still make sense in order to have the package behave identically on all platforms.

To progress, I think activate.{bat,ps1,sh} should append ${PREFIX}/etc/xml/catalog to XML_CATALOG_FILES, using space as a separator. Per @isuruf's comment, activate.sh should additionally append the system location (/etc/xml/catalog) on Unix. For space-separation to work, all paths probably need to be URL-encoded.

I'll try that next.

[hattne]

Obsolete as of #87.