preliminary patch for better POSIX installs

How about installing everything as it's installed on Windows and then creating symlinks in the proper places? Other way around should work as well... This way, the only required changes would be fixing NSISDIR detection and updating the build system to create symlinks.

Hmm, I don't think that is a good idea.

What about a simplification of the current patch where all the subdirectories of PREFIX_DATA cannot be customised. This cuts out all those environment variables and stuff.

Why don't you think it'll be a good solution?

The main reason is that I created this patch was so that I wouldn't have to do such hacks in the debian package.

I can see why you'd consider this a hack, but think of the upsides. Scripts will work out of the box with no need for new defines and the patch will be much simpler. Are there any downsides other than the general feeling of "this is just stitching some patches so it'll connect properly instead of actually porting it"?

Not really.

How about I do the equivalent of the current patch without all the extra defines? The only changes to the current situation would be:

• ${NSISDIR} would point at /usr/local/share/nsis (or /usr/share/nsis on Linux, and contain Contrib, Include, Plugins, Stubs, Bin (win32 only binaries) and Menu (not sure if this should be installed or not).
• The native binaries (makensis/genpat), config file, docs and examples will be located outside of ${NSISDIR}, so you won't be able to load/read/touch them from .nsi scripts (unless I add keep some of the ${NSIS*DIR} variables).
• You will be able to redefine where makensis looks for its data, and config file/etc by using environment variables. This is useful for running scons test without having installed the software
• Since relocatability is fairly foreign to linux/bsd/unix (although it is possible on linux and macos at least), it will be possible to use absolute locations for stuff

Btw, shouldn't RegTool.bin move to Contrib?

Two problems I saw when reverting most of the patch:

• tutorial.but contains this line. That won't be possible any more, and isn't portable anyway (executables don't have the .exe extension on linux/etc). I've just made this NSISDIR for now.

  \c nsExec::ExecToLog '"${NSISBINDIR}\makensis.exe" /CMDHELP'

  Same problem with nsExec's test.nsi and other files.
• compiler.but references licence.txt, which may or may not be installed (debian has other files for copyright info). Reverted to NSISDIR.

Sounds good to me, though, as you've already noticed, there'll be problems with documentation links. Those can be resolved with a symlink located at the documentation location, or halibut's xhtml-rlink-prefix and xhtml-rlink-suffix \cfg options. Those were added for the CHM, but can be used here to add a path prefix to the links in this case as well.

About the documentation links, I think the best option is to post-process the html files with a python function, I'm not sure how to do that though. Writing the function would be easy, just use some regular expressions. Hooking it up to scons is the hard part (at least for me). Any ideas? This could also be used to process the ready-made html files - the System Readme.html and so on.

Attached the cut-down version. Still need to sort out the documentation issue.

On Linux, PREFIX_CONF and PREFIX_DATA are embedded in makensis, dictating where it looks for the config file and the plugins/etc. PREFIX_DEST is like DESTDIR from software that uses automake. Packagers (like debian) generally need to install to somewhere other than / (the root dir), but the resulting executables still need to refer to directories under / instead of where they are installed. For example:

scons PREFIX=/home/pabs/debian/nsis/usr install
create-deb /home/pabs/debian/nsis/

Would result in makensis being installed as /usr/bin/makensis on a users system, and the plugins/etc being installed in /usr/share/nsis/, but makensis would look for the plugins/etc in /home/pabs/debian/nsis/usr/share/nsis/, which of course does not exist on the users system.

I'll try to fix that empty PREFIX thing.

Thanks for the Builder tip, I'll add that today.

With the current CVS code, where does it install nsis to if PREFIX isn't set? Or do you mean it should error out if PREFIX isn't set?

Attached a version that modifies the HTML before installing it. Needs a bit of fixing for Windows I imagine.

In Distribute and DistributeAs, it checks if the environment contains PREFIX. If it doesn't, it doesn't call env.Install() to install to $PREFIX.

I'll check out the new patch on the weekend.

New version that fixes the prefix thing.

I've made some cosmetic improvements. I have edited the patch file as is, without creating it from scratch, for all files but SConscruct. The line numbers may be malformed because of this.

I hope to get the final look next weekend and apply this to CVS.

Excellent. Your changes all look good.

Here's what I have so far. I changed the define name and reversed its meaning and moved all the executables back to their correct paths. Let me know if it works.

Yep, that works fine. Feel free to commit 😁