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've thought about this some more, and I think the ideal solution would
be to have an agent which resides on a machine and can produce
system-specific information. What I'd like is something which is not
part of the program, but local to the machine, yet can be accessed in a
platform-independent way. How about environment variables? As far as I
know they are available on every platform and they are accessible from
C++ via a standard header. To get the information into the program, they
are definitely a viable path. What do you think?
If we were to go with this idea, the question is, how can we *set* the
environment variables in a platform-specific way, i.e. set an
environment variable LUX_GUI_FONT to
/usr/local/share/lux/Sansation_Regular.ttf on ubuntu? We can't use cmake
directly, because it won't be available on the user's machine, so there
must be an indirect way. If the installation process could set the
required variables persistently, builders could modify that step to fit
their needs, and the binary would remain platform-independent. I
wouldn't be surprised if cmake's package-building code would have
built-in support to set environment variables, but I couldn't find it
when I looked just now. One problem with session-wide environment
variables is that they won't be available until the user has logged in
again (speaking about linux here, if we were to modify e.g. ~/.profile)
Another way to have the right environment variable would be to launch
lux via a helper script, which I like anyway because it's a good way for
experienced users to configure the launch. The script can export the
environment variable, then launch lux. I think I'd favor this option.
I have added code to pv_no_rendering.cc to try and glean the value of an
environment variable LUX_GUI_PATH, if neither the GUI font from the
command line (if any) nor in the pwd (if any) can be loaded. It's the
'last resort'. With this option in the code, we can experiment if this
idea is a viable path.
@Bruno: what do you think of this idea?
Kay
--
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/2139dde0-ac52-0d75-3358-d7e952124d5b%40yahoo.com.
