Linux build search Stubs in a different folder

Hello,

i suspect that a simple variable set in the scons command line or in the .nsi file should be able to fix it, but my poor knowledge and searches didn't give any solution yet, so here i'm.

After having build makensis under Fedora and Arch with the following command:
scons SKIPSTUBS=all SKIPPLUGINS=all SKIPUTILS=all SKIPMISC=all NSIS_CONFIG_CONST_DATA_PATH=no NSIS_CONFIG_LOG=yes PREFIX=~/nsis-3.03-src install-compiler

The necessary folders need for NSIS 3.03 Log version have been downloaded from Sourceforge and placed into the same folder as makensis.

I can make use of it from Maven pom.xml on Fedora and Arch if i put it into a folder one level deeper to be able that makensis find the folders like Stubs, plugin...

But when i run it on Ubuntu and Mint, as any Debian based distribution i guess, makensis search the folder need in /usr/share/maven.

So any help would be much appreciated 😉

I should have said that Fedora and Arch use the Maven 3.5.2 version and that the Debian based distributions have Maven 3.3.9 installed, in case it could explain the different result.
The Maven plugin used is nsis-maven-plugin 1.0-alpha-1 version.

I have no clue what Maven is and makensis doesn't either, it just looks in it's subfolder or on POSIX, some other folder you configured when building with NSIS_CONFIG_CONST_DATA_PATH and the other related SCons settings.

Thank you very much 🙂
That did the trick.

I don't know if it is a NSIS bug or me not configuring correctly but i get that error when trying on a "foreign" computer:

It seem that the path get hardcoded.

Here the command line used to build makensis:
Any idea what is wrong?

Is there is a way to set ~ (HOME) in the path without making it abolute or "converted"?

Maybe escape ~ (I assume your shell expands it?). Not sure if makensis will expand ~ though. Or just use /usr/local/nsis or something like that.

Your help is much appreciated +1

We use GNU bash version 4.4.23. I never get any issue before, but as i'm unfamiliar with scons that could also come from that.

That is said, the Windows build that you've made work fine on any Windows computer.
In case i wasn't clear on that, it is used as a portable NSIS included in the source of a project ready to be used by developpers or users to make builds without the need to install NSIS if they didn't.
Before that it was depending on system user NSIS install. So we just try to get rid of that for Linux users.

I'll give a try and report back.

It seem that it is expecting for some absolute path only.

[INFO] [MAKENSIS] Error: reading stub "~/DigitalMediaServer/src/main/external-resources/third-party/nsis/Stubs/zlib-x86-ansi"
[INFO] [MAKENSIS] Error initalizing CEXEBuild: error setting default stub

I was hoping to avoid using symlink 🙁

This thread covers the topic better than I can: http://forums.winamp.com/showthread.php?t=266976

"NSIS_CONFIG_CONST_DATA_PATH=no" seems like the better option for your needs, maybe focus on getting that working?

Setting to "no" was my first try but it wasn't working because it expected the Stubs to be in the default Linux place set by SContruct.

Thank you for sharing the link, i'll look at it.

Ok, i could have wrongly understood the post but it seem that i'll have to use symlink to be able to get it run for every developper/users using the NSIS files already in ~/DigitalMediaServer/src/main/external-resources/third-party/nsis 🙁

As we tried to avoid symlink and setting anything outside our own NSIS folder that are not root and imported when cloning our Github repository, i'm afraid that we will have to use symlink for the PREFIX_DATA.

Thank you for your help +1

As a side note as i said early when i've set "NSIS_CONFIG_CONST_DATA_PATH=no" it searched the "ZIP" folders into the folder of superior level so i've to put makensis executable into its own folder but as it searched into /usr/share/maven on Debian based OS it was not uniform between Linux OS as i expected so not usable, at least for our use case.

The problem to have to set a symlink in this root folder is that it will ask user to enter their root password if they are not admin.

It seems strange that the behavior depends on the system. Might be a bug related to how makensis finds its own path, it should not search a higher level directory. What does "!echo ${NSISDIR}" say? You could also try to add a printf call in the code, IIRC it's a function in Source\Util.cpp that finds the executable path.

Hum...as i do not have any C skill, could you point me where i should add a ?



When running on Fedora or Arch Linux from the /home/sami folder it expect the Stubs folder to be in a folder the level before: (as my english is weak here an example)

This command was used:

It has been run from the /home/sami/ folder

*C++

Hum...i come to suspect the Maven plugin used to make a such difference under Debian based distributions:
[MAKENSIS] Error: reading stub "/usr/share/maven/Stubs/zlib-x86-ansi"

Because when run manually it throw the same error as above, that could be easily worked by set makensis Linux binary in a folder a level deeper.

[SOLVED] Linux build search Stubs in a different folder

Yes, that was NSISDIR value not set correctly, enforced.
Thank you for your advise :-)