čt 18. 3. 2021 v 11:31 odesílatel Bruno Postle <[email protected]> napsal: > > On Thu 18-Mar-2021 at 09:56 +0100, Hugin ptx wrote: > >Am 17.03.21 um 19:11 schrieb Kornel Benko: > >>Am Wed, 17 Mar 2021 17:52:10 +0100 > >>schrieb "'Kay F. Jahnke' via hugin and other free panoramic software" > > > >>>@Kornel: Maybe cmake can produce something like a pv_config.h header > >>>which has such platform-specific information? That should not be too > >>>hard - and it might be nice to maybe have a bit more platform-specific > >>>info at hand, like the user's home directory, to put stuff in which > >>>persists from session to session, and the location of the binary... > >>> > >>>I wouldn't be surprised if cmake does that all the time - I'm just not > >>>very good at it. > >> > >>I can do that. I have to know the variable-names and their value. > >>And of course the desired name of the header file. > > > >Sorry, @Kornel, I think this was yet another one of my quick shots. I > >have doubts now after sleeping over it. If you were to generate a C++ > >header file which is compiled into the program, the resulting binary > >contains a hard-coded path - even if this is only the third option if > >the other two options fail. Can we be sure that such a binary will not > >be produced/used on another platform/distro where it's bound to fail? > > I think it is normal for a Linux binary to use a hard-coded path > determined at build time. Either you are compiling yourself and > installing to /opt/lux or /usr/local or ~/.local, or using a package > manager (deb or rpm) that installs to /usr. There is no expectation > that you can move stuff around after installation. > > You can propogate the CMAKE_INSTALL_PREFIX to a C++ macro using the > -D convention, this way you just #ifdef INSTALL_PREFIX etc... You > shouldn't have to create any temporary .h files (though there are > people here who understand this stuff much better than I do). > > If you do want users to be able to move stuff around, then the > software can fall back to looking for the font in the same folder as > the binary, as it does now. > > Another approach, which probably doesn't appeal, is that cmake will > surely have a standard platform-independent method of installing a > font into the system font directory, where it is available to all > applications. The problem with this is you then have to figure out > how to get lux to load a font from the system font directory on all > platforms. > > Setting an environment variable at install time isn't so > straightforward, there is no guarantee a user has a ~/.profile file, > do you try and append it to /etc/profile or drop a file in > /etc/profile.d/ (not all systems have a profile.d). This will break > easily and you will have to deal with users asking for help. > > A wrapper script is a better idea, though having lux check the > LUX_GUI_FONT environment at runtime is a good idea anyway. > > I would do all these: hard-code the INSTALL_PREFIX and look there, > otherwise check LUX_GUI_FONT at runtime, fall-back to looking in the > same folder, finally fail with an error.
Personally, I would add one more as a last one: compiled-in font that will be always available Regards David -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CACjcME%2BMiC7DFrgP8RGM1Y1hV8q%2BHwqCoG_6RH6GdE4OR%2BuLZg%40mail.gmail.com.
