[Flightgear-devel] [flightgear:flightgear] New commit [b2cc19] by Florent Rougon

[James Turner]

${CMAKE_SOURCE_DIR}/src/EmbeddedResources/FlightGear-resources.xml
(currently empty) is automatically "compiled" into
${CMAKE_BINARY_DIR}/src/EmbeddedResources/FlightGear-resources.[ch]xx by
fgrcc inside the build directory. These files are incorporated into the
FlightGear build (FlightGear-resources.cxx is linked into FlightGear).

Unfortunately, this has broken my Windows build setup, because zlib.dll is not in the PATH, and hence fgrcc fails to run.

CMake doesn’t seem to have a way to inject a PATH when running a custom command, but I didn’t check exhaustively.

I can hack around by adding the relevant dir to my PATH in my build wrapper script, but I wonder if there is a more generic solution, since we know zlib.dll must existing in the 3rdparty dir.

Kind regards,
James

[Florent Rougon]

Hi,

Post by James Turner
Unfortunately, this has broken my Windows build setup, because zlib.dll is not
in the PATH, and hence fgrcc fails to run.
CMake doesn’t seem to have a way to inject a PATH when running a custom
command, but I didn’t check exhaustively.
I can hack around by adding the relevant dir to my PATH in my build wrapper
script, but I wonder if there is a more generic solution, since we know
zlib.dll must existing in the 3rdparty dir.

Thanks, I was suspecting this but couldn't be sure since the build log
doesn't say much. However, it seems it's possible to modify the PATH at
build time, see:

https://stackoverflow.com/questions/28533012/how-to-set-runtime-path-for-cmake-custom-command-on-windows

I just don't know exactly which path should be indicated for Windows...
If you or someone else could find this, that would be very helpful.

Thanks

[Florent Rougon]

Post by Florent Rougon
https://stackoverflow.com/questions/28533012/how-to-set-runtime-path-for-cmake-custom-command-on-windows
I just don't know exactly which path should be indicated for Windows...
If you or someone else could find this, that would be very helpful.

According to <https://cmake.org/Wiki/CMake:How_To_Find_Libraries>, it
seems to me that:

find_package(SimGear ...)

should leave us with ${SimGear_LIBRARIES} giving the desired directory.
We already have such a call in flightgear/CMakeLists.txt. I don't know
if it has to be repeated in flightgear/src/Main/CMakeLists.txt in order
to have the 'SimGear_LIBRARIES' CMake variable also set there. Assuming
yes, combining this with:

https://stackoverflow.com/a/32592820/4756009

suggests that a possible solution could look like this:

add_custom_command(
OUTPUT ${CMAKE_BINARY_DIR}/src/EmbeddedResources/FlightGear-resources.cxx
${CMAKE_BINARY_DIR}/src/EmbeddedResources/FlightGear-resources.hxx
COMMAND ${CMAKE_COMMAND} -E env "PATH=${SimGear_LIBRARIES}" $<TARGET_FILE:fgrcc> --root=${CMAKE_SOURCE_DIR} --output-cpp-file=${CMAKE_BINARY_DIR}/src/EmbeddedResources/FlightGear-resources.cxx --init-func-name=initFlightGearEmbeddedResources --output-header-file=${CMAKE_BINARY_DIR}/src/EmbeddedResources/FlightGear-resources.hxx --output-header-identifier=_FG_FLIGHTGEAR_EMBEDDED_RESOURCES ${CMAKE_SOURCE_DIR}/src/EmbeddedResources/FlightGear-resources.xml
DEPENDS
fgrcc ${CMAKE_SOURCE_DIR}/src/EmbeddedResources/FlightGear-resources.xml
)

for Windows (this is in flightgear/src/Main/CMakeLists.txt; replace the
already existing similar block. I attached the patch to be clear. Of
course, you might need to add a find_package(SimGear ...) call in case
the one from the root CMakeLists.txt doesn't propagate the
'SimGear_LIBRARIES' variable).

If this works, we may have to make a special case of this block for
Windows. Can you (or someone else) try something like that, or a
solution of your own?

Many thanks!

[James Turner]

Post by Florent Rougon
According to <https://cmake.org/Wiki/CMake:How_To_Find_Libraries>, it
find_package(SimGear ...)
should leave us with ${SimGear_LIBRARIES} giving the desired directory.
We already have such a call in flightgear/CMakeLists.txt. I don't know
if it has to be repeated in flightgear/src/Main/CMakeLists.txt in order
to have the 'SimGear_LIBRARIES' CMake variable also set there. Assuming
https://stackoverflow.com/a/32592820/4756009

Alas, it doesn’t quite work that way: SimGear_LIBRARIES contains the absolute path to SimGear.lib; this is the way CMake is moving rather than having -lfoo and -L prefixes

On Mac and Linux the library path gets embedded.

However, the Stackoverflow page does suggest setting CMAKE_MSVCIDE_RUN_PATH, which is what I will do shortly, to:

$CMAKE_INSTALL_PREFIX/bin:$WINDOW_3RDPARTY/arch/bin

I didn’t know about this variable and it will fix the long-standing issue of my needed to set these values in VS before running FG anyway.

Kind regards,
James

[Florent Rougon]

Alas, it doesn’t quite work that way: SimGear_LIBRARIES contains the absolute
path to SimGear.lib; this is the way CMake is moving rather than having -lfoo
and -L prefixes

Not sure exactly what this SimGear.lib is, so I don't really understand
what you are saying here. Is it a static library? Or the equivalent of a
.so file, for use at build time (as opposed to .dll then)?

Since SimGear is a dependency of FlightGear, there must be some way,
even on Windows, to run an executable linked to it at FG build time...

On Mac and Linux the library path gets embedded.

You mean with rpath? I don't use -DSIMGEAR_SHARED=ON, so no wonder it
works for me (static linking), but indeed when this setting is used,
there must be something like that (or CMake modifying LD_LIBRARY_PATH
for the add_custom_command() run...) to allow running an executable
linked to SimGear directly from the build directory.

However, the Stackoverflow page does suggest setting CMAKE_MSVCIDE_RUN_PATH,
$CMAKE_INSTALL_PREFIX/bin:$WINDOW_3RDPARTY/arch/bin
I didn’t know about this variable and it will fix the long-standing issue of
my needed to set these values in VS before running FG anyway.

I'm literally hanging on your words. :)
(and crossing fingers)

Thanks!

[Geoff McLane]

Post by Florent Rougon

Alas, it doesn’t quite work that way: SimGear_LIBRARIES contains the absolute
path to SimGear.lib; this is the way CMake is moving rather than having -lfoo
and -L prefixes

Not sure exactly what this SimGear.lib is, so I don't really understand
what you are saying here. Is it a static library? Or the equivalent of a
.so file, for use at build time (as opposed to .dll then)?
Since SimGear is a dependency of FlightGear, there must be some way,
even on Windows, to run an executable linked to it at FG build time...

SimGear.lib is a static library, but it will contain dependencies
on other DLLs, like zlib.dll, ...

So to run executables linked to it, one must modify, temporarily,
the PATH env variable...

I generally use this layout -
http://wiki.flightgear.org/Building_using_CMake_-_Windows

And use 'subst X: F:\Projects', so MSVC_3RDPARTY_ROOT is just X:
so to modify the PATH to run say 'fgfs' I need to do -

@setlocal
@REM For DLLS like zlib.dll
@set TMP3RD=X:\3rdParty.x64\bin
@REM For OSG DLLS
@set TMPOSG=X:\install\msvc140-64\OpenSceneGraph\bin
@REM and maybe others, like Boost, etc...

@set PATH=%TMP3RD%;%TMPOSG%;%PATH%

Then I can run 'fgfs.exe [commands]'

Welcome to the world of Windows ;=))

Regards,
Geoff.

[James Turner]

Post by Florent Rougon
Not sure exactly what this SimGear.lib is, so I don't really understand
what you are saying here. Is it a static library? Or the equivalent of a
.so file, for use at build time (as opposed to .dll then)?
Since SimGear is a dependency of FlightGear, there must be some way,
even on Windows, to run an executable linked to it at FG build time


The .lib is the link lib used by the linker. The DLL is only used at runtime and can be in a totally difference place / path. So the Simgear_LIBRARIES on Windows doesn’t mention DLLs at all.

Post by Florent Rougon

Post by James Turner
On Mac and Linux the library path gets embedded.

You mean with rpath? I don't use -DSIMGEAR_SHARED=ON, so no wonder it
works for me (static linking), but indeed when this setting is used,
there must be something like that (or CMake modifying LD_LIBRARY_PATH
for the add_custom_command() run...) to allow running an executable
linked to SimGear directly from the build directory.

Correct, we use Rpath on Mac and Linux, and because we use Cmake imported/exported targets, transitive deps of Simgear (even static simgear) are passed on when linking FGFS. (This is a major reason we use CMake exported targets this way)

So again, it’s only Windows that needs fixed, and we ‘just’ need to get the 3rdparty dir, and possibly the install-prefix bin dir, into PATH, which the variable I mentioned in my previous email will let us do.

However, I’m now on the road until Wednesday night. This means more progress on a Qt UI (since I will be hanging around in airport lounges) but none on Windows since I am away from that box.

Kind regards,
James

[Geoff McLane]

Post by James Turner
The .lib is the link lib used by the linker.

As James points out there are two types of libraries
in windows...

I thought we were talking about 'static' SimGearCore.lib
and SimGearScene.lib... equivalent to the *.a library
in unix...

But if we are talking about shared libraries in Windows,
then there are two files, like zlib.lib and zlib.dll.
Equivalent to the *.so library in unix...

When cmake searches for zlib it will only find the
zlib.lib, usually residing in the 'lib' directory, and
it will be used to make the link...

When you want to run an app either directly linked with
zlib.lib, or indirect through SimGearCore.lib, then
the zlib.dll must be found... It usually resides in the
'bin' directory...

Have just updated to the latest SG/FG/FGDATA, and the
FG build fails in the CustomBuild: Generating ...resources.cxx/hxx
due to the tool not being able to find zlib.dll in
the current PATH...

Will experiment with some solutions offered here,
particularly setting the undocumented CMAKE_MSVCIDE_RUN_PATH,
or the other solutions offered...

See how far I get...

Regards,
Geoff.

[Florent Rougon]

Hi,

Post by Geoff McLane
Will experiment with some solutions offered here,
particularly setting the undocumented CMAKE_MSVCIDE_RUN_PATH,
or the other solutions offered...
See how far I get...

Many thanks to both of you. Attaching a possible fix (or starting point)
using the ideas exchanged here if you want to try it. You might also
need to add ${CMAKE_BINARY_DIR}/src/EmbeddedResources to the variable
(where the just-built fgrcc should be), but I'd first try without. And
possibly also something under ${MSVC_3RDPARTY_ROOT}/SimGear/... for
SimGear. :-)

Thanks & regards

[Florent Rougon]

I forgot this in the patch:

include(ConfigureMsvc3rdParty)

[Geoff McLane]

On 12/06/17 16:22, Florent Rougon wrote:

Was preparing, researching this before I got your
next 2... will deal with them at the end...

Wow, seems quite a while since I looked at the FG
cmake system... one thing noted is that it no
longer uses FindSimGear.cmake!

Not that knowing where SimGear is would help, but
I seem to remember it also did a FindZLIB... then
we could use the ZLIB_INCLUDE_DIRS as the potential
location of the zlib.DLL, like -

set(CMAKE_MSVCIDE_RUN_PATH "${ZLIB_INCLUDE_DIRS}/../bin")

Of course, since I use an X:/build-fg/build-me.bat, which
already sets a host of variables, including the QT5_DIR,
to find my 64-bit Qt5 install, etc, I was able to complete
the build by adding just one line to it -

@set PATH=%TMP3RD%/bin;%PATH%

Since that worked, I removed that and added to the
cmake command line -

@set CMOPTS=%CMOPTS% -DCMAKE_MSVCIDE_RUN_PATH=%TMP3RD%/bin

and that worked as well... so setting that variable seems
a very viable solution...

Just a little concerned over what to add to the
CMakeLists.txt... like -

set(CMAKE_MSVCIDE_RUN_PATH $(TO_WHAT)) # ?????

As far as I can see the WINDOW_3RDPARTY suggested by James
does not exist... and CMAKE_INSTALL_PREFIX is, in this
case X:/include/msvc140-64/flightgear so is not helpful...

Although the desired X:/3rdParty.x64/bin probably does exist in
the CMAKE_PREFIX_PATH, but it is not singular... it also
contains OSG and SG paths, and more...

I suppose could do a messy
set(_MSVC_PATH)
foreach( path ${CMAKE_PREFIX_PATH} )
list(APPEND _MSVC_PATH "${path}/bin")
endforeach()
set(CMAKE_MSVCIDE_RUN_PATH "$(_MSVC_PATH)") # Might work
but looks, and feels ugly...

After adding some code to enumerate every defined
variable...

AH HA, there is still a MSVC_3RDPARTY_ROOT set, so could
add '/bin' to that...

AND I find that ZLIB_INCLUDE_DIR does exist...
so could do what I suggested first above...

So, there are now several possibilities -

1. Tell Windows builders about this and they set either
the PATH or the variable before running cmake... and
adjust jenkin win batch build accordingly...

2. Choose one of the above options to set the
MSVCIDE variable in src/Main/CMakeLists.txt, probably
MSVC_3RDPARTY_ROOT is best...

Lots of options ;=))

Concerning your patch - yes, nearly looks good -

a. include(ConfigureMsvc3rdParty) is already done
b. seems you can not combine 3RDPARTY_ROOT and DIR, the
ROOT is already a full path...
c. not sure why you needed to change the COMMAND... in
Windows just 'fgrcc' works fine... or did you change something
else...

So it seems you like the option 2. above, which is
fine... but fix it to just ROOT... and we're good to go...

Regards,
Geoff.

[Florent Rougon]

Post by Geoff McLane
Concerning your patch - yes, nearly looks good -
a. include(ConfigureMsvc3rdParty) is already done

Yes, but only in the root CMakeLists.txt, whereas we specifically need
it in src/Main/CMakeLists.txt (flightgear repo, of course). However, I
believe this is enough: the variables it sets should be visible in
src/Main/CMakeLists.txt, if I understand the scoping rules at
<https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#cmake-language-variables>
correctly. So indeed, adding the include is probably unnecessary (but
would be cleaner if we were sure that a CMake file included a second
time is just skipped---I doubt it, but am not a CMake expert!).

Post by Geoff McLane
b. seems you can not combine 3RDPARTY_ROOT and DIR, the
ROOT is already a full path...

In this case, I believe you are mistaken. Please see this excerpt from
flightgear/CMakeModules/ConfigureMsvc3rdParty.cmake:

if (CMAKE_CL_64)
set( OSG_MSVC ${OSG_MSVC}-64 )
set( MSVC_3RDPARTY_DIR 3rdParty.x64 )
set( BOOST_LIB lib64 )
else (CMAKE_CL_64)
set( MSVC_3RDPARTY_DIR 3rdParty )
set( BOOST_LIB lib )
endif (CMAKE_CL_64)

set (CMAKE_LIBRARY_PATH ${MSVC_3RDPARTY_ROOT}/${MSVC_3RDPARTY_DIR}/lib ${MSVC_3RDPARTY_ROOT}/install/${OSG_MSVC}/OpenScenegraph/lib ${MSVC_3RDPARTY_ROOT}/install/${OSG_MSVC}/OpenRTI/lib ${MSVC_3RDPARTY_ROOT}/install/${OSG_MSVC}/SimGear/lib )

MSVC_3RDPARTY_DIR only contains the leaf part of the full path.

Post by Geoff McLane
c. not sure why you needed to change the COMMAND... in
Windows just 'fgrcc' works fine... or did you change something
else...

I didn't change anything else, just discovered this syntax
($<TARGET_FILE:foobar>) after I committed the stuff, and thought it
might be more reliable with respect to using the correct path for fgrcc.
However, my commit was directly inspired from:

https://cmake.org/cmake-tutorial/

which doesn't use this syntax---maybe the tutorial is a bit outdated. I
have tested with and without this change on Linux, both work. Unless it
causes problems, I'd be inclined to keep the change (i.e., use
$<TARGET_FILE:fgrcc>).

Concerning earlier parts of your message, I don't think we need to
fiddle with INCLUDE paths, because AFAICS from jenkins, there is no
problem building fgrcc. It is running it as part of the FG build process
that is currently problematic.

Post by Geoff McLane
So it seems you like the option 2. above, which is
fine... but fix it to just ROOT... and we're good to go...

Given what we said about the unnecessary
'include(ConfigureMsvc3rdParty)', I believe the last patch I sent has
good chances to work. If you could confirm, I would commit it (and then
James could further massage it the way he wants when he's back home, for
the other use cases he has in mind for this nice 'CMAKE_MSVCIDE_RUN_PATH'
variable :).

Regards

[Geoff McLane]

On 12/06/17 18:39, Florent Rougon wrote:

Hi,

My bad! I had been setting MSVC_3RDPARTY_ROOT
in my build-me.bat batch file, which I have been
using successfully for /YEARS/, and it seems
cmake chooses to not change it if set on the
command line... strange...

And even stranger that my build works, even
with a very messed up CMAKE_LIBRARY_PATH...

One small thing is that the MSVC_3RDPARTY_ROOT
is now set to "X:/" so we get a double "//" from the
likes of ${MSVC_3RDPARTY_ROOT}/${MSVC_3RDPARTY_DIR}/lib,
but usually cmake and windows have no particular problem
with this...

Concerning the jenkins build, not suggesting changing
the INCLUDE paths at all...

As I understand it, the win jenkin directory setup is as shown
in the wiki, and just pointed out that either the PATH set
to the X:/3rdParty.x64/bin or the MSVCIDE_RUN_PATH can be set
externally, in the batch file that runs the build...

IE, no need to change cmake files... but BOTH work...

Will certainly get around to testing your
patch, but that will probably be tomorrow... or
soonest... thanks...

Regards,
Geoff.

[Florent Rougon]

Post by Geoff McLane
My bad! I had been setting MSVC_3RDPARTY_ROOT
in my build-me.bat batch file, which I have been
using successfully for /YEARS/, and it seems
cmake chooses to not change it if set on the
command line... strange...

Well, that's possible. At least, Make can exhibit this kind of behavior
too, depending on how variables are defined in a Makefile.

Post by Geoff McLane
One small thing is that the MSVC_3RDPARTY_ROOT
is now set to "X:/" so we get a double "//" from the
likes of ${MSVC_3RDPARTY_ROOT}/${MSVC_3RDPARTY_DIR}/lib,
but usually cmake and windows have no particular problem
with this...

In
<http://doc.aldebaran.com/qibuild/hacking/contrib/cmake/coding_guide.html>
they advise *not* to have the CMake variables end up with a slash, for
this very reason and because when converted to native format, a path
with // could become one with \\, which has a particular meaning on
Windows (UNC paths). Unfortunately, this doesn't apply well to the case
of a device root dir on Windows, since X: means "current directory on
device X" which is not what you want (it would work if the variable
expansion were always followed by '/something', of course). It looks
somewhat ugly, but maybe 'X:/.' would be safe?

(I looked for a CMake function to cleanly assemble path components like
Python's os.path.join(), but couldn't find one)

Post by Geoff McLane
Concerning the jenkins build, not suggesting changing
the INCLUDE paths at all...

Okay.

Post by Geoff McLane
As I understand it, the win jenkin directory setup is as shown
in the wiki, and just pointed out that either the PATH set
to the X:/3rdParty.x64/bin or the MSVCIDE_RUN_PATH can be set
externally, in the batch file that runs the build...
IE, no need to change cmake files... but BOTH work...

Yes, I believe James precisely said that so far, he used to modify PATH
externally for his Windows FG builds for this kind of reason. However,
since there seems to be a more automatic solution, it seems worth to try
for better user-friendliness.

Post by Geoff McLane
Will certainly get around to testing your
patch, but that will probably be tomorrow... or
soonest... thanks...

Cool, thanks.

Regards

[James Turner]

Post by Florent Rougon
Yes, I believe James precisely said that so far, he used to modify PATH
externally for his Windows FG builds for this kind of reason. However,
since there seems to be a more automatic solution, it seems worth to try
for better user-friendliness.

Yes, this is what I intend to do once home.

Kind regards,
James

[Geoff McLane]

On 12/06/17 23:35, Florent Rougon wrote:

Hi,

Post by Florent Rougon

Will certainly get around to testing your patch, ...

Cool, thanks.

Using latest, commit f55fd3f, did a clean build FG,
after patching src/Main/CMakeLists.txt per your
patch, and no problem...

Have not had a chance to run the resultant 'fgfs.exe',
will get to that, but certainly 'fgrcc' ran ok, and
produced the two source files...

And did not need to do a second include of the cmake
ConfigureMsvc3rdParty...

A few questions... but quite minor...

1. Should **not** finding MSVC_3RDPARTY_ROOT or DIR be
a FATAL_ERROR? I could be using a static zlibstatic.lib,
or already have the PATH fixed, etc, etc... several
reason why this may not be **fatal**...

I can see a WARNING for sure... but to abort the
build...

2. Just a question, but why 'bury' the generated
sources so deep into the 'build' directory system?

You could just put them in ${CMAKE_BINARY_DIR}, which
should already be an out-of-source build directory,
which is even tested and warned against...

This is not really a problem where you put them,
but it would certainly serve to reduce the length of
the current giant add_custom_command(...)

Anyway, as stated, these are minor, and had a
successful FG build with your patch... thanks...

Regards,
Geoff.

[Florent Rougon]

Hi,

Thanks for your feedback.

Post by Geoff McLane
Using latest, commit f55fd3f, did a clean build FG,
after patching src/Main/CMakeLists.txt per your
patch, and no problem...

Argh, it's puzzling. Some time before your mail, I had already pushed
0855f0414, which is:

diff --git a/src/Main/CMakeLists.txt b/src/Main/CMakeLists.txt
index 68a86f09b..8ae90d2cc 100644
--- a/src/Main/CMakeLists.txt
+++ b/src/Main/CMakeLists.txt
@@ -44,6 +44,16 @@ set(HEADERS
${CMAKE_BINARY_DIR}/src/EmbeddedResources/FlightGear-resources.hxx
)

+# On Windows, make sure fgrcc can be run (it needs third-party libraries)
+if (MSVC)
+ if (MSVC_3RDPARTY_ROOT AND MSVC_3RDPARTY_DIR)
+ set(CMAKE_MSVCIDE_RUN_PATH ${MSVC_3RDPARTY_ROOT}/${MSVC_3RDPARTY_DIR}/bin)
+ else ()
+ message(FATAL_ERROR
+ "Either MSVC_3RDPARTY_ROOT or MSVC_3RDPARTY_DIR is empty or unset")
+ endif ()
+endif ()
+
add_custom_command(
OUTPUT ${CMAKE_BINARY_DIR}/src/EmbeddedResources/FlightGear-resources.cxx
${CMAKE_BINARY_DIR}/src/EmbeddedResources/FlightGear-resources.hxx

i.e., the same as the patch I posted earlier, but with just 'fgrcc'
instead of '$<TARGET_FILE:fgrcc>' (the CMake documentation for
add_custom_command()[1] clearly states that using $<TARGET_FILE:...> in
this case isn't necessary, so I finally decided not to use it in order
to make the command a bit more readable---and it does work this way on
my Linux box, which means the correct path is used, because I don't have
fgrcc in my PATH).

[1] https://cmake.org/cmake/help/latest/command/add_custom_command.html?highlight=target_file
https://cmake.org/cmake/help/v3.2/command/add_custom_command.html?highlight=target_file
https://cmake.org/cmake/help/v3.0/command/add_custom_command.html?highlight=target_file

And this still doesn't work on jenkins. Maybe it doesn't find SimGear,
or... The error message is absolute rubbish, of course:

Generating ../EmbeddedResources/FlightGear-resources.cxx, ../EmbeddedResources/FlightGear-resources.hxx
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code -1073741511. [G:\Jenkins\workspace\FlightGear-Win\build32\src\Main\fgfs.vcxproj]
Done Building Project "G:\Jenkins\workspace\FlightGear-Win\build32\src\Main\fgfs.vcxproj" (default targets) -- FAILED.

Post by Geoff McLane
1. Should **not** finding MSVC_3RDPARTY_ROOT or DIR be
a FATAL_ERROR? I could be using a static zlibstatic.lib,
or already have the PATH fixed, etc, etc... several
reason why this may not be **fatal**...
I can see a WARNING for sure... but to abort the
build...

Because I wanted to make the reason clearly apparent when the build
fails here, but if there is a supported configuration without these
settings, the message level can be changed, sure. Would the rest of the
build work with these variables unset?

Post by Geoff McLane
2. Just a question, but why 'bury' the generated
sources so deep into the 'build' directory system?
You could just put them in ${CMAKE_BINARY_DIR}, which
should already be an out-of-source build directory,
which is even tested and warned against...
This is not really a problem where you put them,
but it would certainly serve to reduce the length of
the current giant add_custom_command(...)

With or without, the command will be a bit long anyway, but no one has
to type it, so... It seems more tidy to me this way, the build dir
corresponding to the source dir containing all related FG files. Of
course, if people really want these files elsewhere, this can be done.

Post by Geoff McLane
Anyway, as stated, these are minor, and had a
successful FG build with your patch... thanks...

You maybe, but not jenkins, alas... :-|

Regards

[Geoff McLane]

On 13/06/17 20:02, Florent Rougon wrote:

Hi,

Post by Florent Rougon
Argh, it's puzzling. Some time before your mail,

I will catch up to that, but it represent no
real change to what I tried, so expect it to
work... that will be tomorrow, or soonest...

My reading of COMMAND is, "If COMMAND specifies an
executable target (created by ADD_EXECUTABLE) - which
this is - it will automatically be replaced by the
location of the executable created at build time."

So I 100% agree with just using 'fgrcc`. The other
looked 'messy', and the cmake docs are clear to me.

And remember, in windows that would change, depending
on the config being built at the time -

Debug: X:/build-fg/src/EmbeddedResources/Debug/fgrcc.exe
Release: X:/build-fg/src/EmbeddedResources/Release/fgrcc.exe

And that reminds me of another line missing from the
CMakeLists.txt build of 'fgrcc', namely -

if (MSVC)
set_target_properties( fgrcc PROPERTIES DEBUG_POSTFIX d)
endif ()

Regrettably, this is not done universally, but for example
see src/FDM/JSBSim/CMakeLists.txt. It would be preferred
that this was added to every ADD_EXECUTABLE...

It is a way to keep the Debug EXE, say 'fgrccd.exe',
which in turn may be linked to SimGearCored.lib, and
zlibd.lib, requiring zlibd.dll, separate from
the Release EXE, say 'fgrcc.exe', SimGearCore.lib,
zlib.lib...

Something preferred by most, maybe all, MSVC devs...
probably not well understood by *nix devs...

Post by Florent Rougon
And this still doesn't work on jenkins.

Well the error you showed is exactly that from the
attempt to run 'fgrcc', and nothing to do with
finding SimGear...

If the jenkins build uses the fgmeta
build_release_windows.bat, like I had, it also
sets -DMSVC_3RDPARTY_ROOT= to a specific place,
and thus -

+ set(CMAKE_MSVCIDE_RUN_PATH
${MSVC_3RDPARTY_ROOT}/${MSVC_3RDPARTY_DIR}/bin)

would just **not** be correct...

Maybe remove that line from the batch file, if
that is what jenkins uses, and it may do better...

Regards,
Geoff.

[Florent Rougon]

Post by Geoff McLane
And remember, in windows that would change, depending
on the config being built at the time -
Debug: X:/build-fg/src/EmbeddedResources/Debug/fgrcc.exe
Release: X:/build-fg/src/EmbeddedResources/Release/fgrcc.exe

Okay.

Post by Geoff McLane
And that reminds me of another line missing from the
CMakeLists.txt build of 'fgrcc', namely -
if (MSVC)
set_target_properties( fgrcc PROPERTIES DEBUG_POSTFIX d)
endif ()

It's a bit strange CMake doesn't do this by default if this is standard
practice, but no pb adding this after the current build problem is
fixed.

Post by Geoff McLane
Regrettably, this is not done universally, but for example
see src/FDM/JSBSim/CMakeLists.txt. It would be preferred
that this was added to every ADD_EXECUTABLE...

Okay.

Post by Geoff McLane
Well the error you showed is exactly that from the
attempt to run 'fgrcc', and nothing to do with
finding SimGear...

Yes, I understand this. What I meant is that fgrcc needs SimGear to run,
and maybe running fgrcc during the FG build process fails precisely
because SimGear can't be found by the runtime linker *for running fgrcc*
(not for the general checks at the start of the FG build process). This
is assuming SimGear is dynamically linked into fgrcc; if you have static
linking instead, this problem can't happen.

Post by Geoff McLane
If the jenkins build uses the fgmeta
build_release_windows.bat, like I had, it also
sets -DMSVC_3RDPARTY_ROOT= to a specific place,

At
<http://build.flightgear.org:8080/job/FlightGear-Win/lastFailedBuild/console>
I see:

G:\Jenkins\workspace\FlightGear-Win\build32>cmake ..\source -G "Visual Studio 14 2015" -DENABLE_PROFILE=OFF -DBOOST_INCLUDEDIR:PATH="G:\jenkins\workspace\FlightGear-Win" -DMSVC_3RDPARTY_ROOT:PATH="G:\jenkins\workspace\FlightGear-Win" -DCMAKE_PREFIX_PATH:PATH="D:\Qt\5.6\msvc2015;G:\jenkins\workspace\FlightGear-Win/install/msvc140/SimGear" -DCMAKE_INSTALL_PREFIX:PATH="G:\jenkins\workspace\FlightGear-Win/install/msvc140/FlightGear"

So we have

-DMSVC_3RDPARTY_ROOT:PATH="G:\jenkins\workspace\FlightGear-Win"

Post by Geoff McLane
and thus -
+ set(CMAKE_MSVCIDE_RUN_PATH
${MSVC_3RDPARTY_ROOT}/${MSVC_3RDPARTY_DIR}/bin)
would just **not** be correct...

I don't see where the problem is... The above paths and variables, plus
the already-posted excerpt from
flightgear/CMakeModules/ConfigureMsvc3rdParty.cmake, seem consistent
with the layout at
<http://wiki.flightgear.org/Building_using_CMake_-_Windows> (link you
gave earlier).

So, assuming this layout, we should have the SimGear install in
${CMAKE_INSTALL_PREFIX}/../SimGear (but which subdir for the DLL? 'bin'?
'lib'? The wiki page doesn't mention 'bin' here, and neither does
flightgear/README.msvc).

In an earlier message, James mentioned using $CMAKE_INSTALL_PREFIX/bin.
I fear it might be too early in the FG install process to have FG's
${CMAKE_INSTALL_PREFIX} dir already filled. Can you tell where you see
the SimGear DLL? I would expect ${CMAKE_INSTALL_PREFIX}/../SimGear/bin
or ${CMAKE_INSTALL_PREFIX}/../SimGear/lib, where ${CMAKE_INSTALL_PREFIX}
is of course the one from the *FG* cmake run.

Thanks

[Geoff McLane]

Hi,

Thanks for the feedback...

Post by Florent Rougon

Post by Florent Rougon
if (MSVC)
set_target_properties( fgrcc PROPERTIES DEBUG_POSTFIX d)
endif ()

It's a bit strange CMake doesn't do this by default if
this is standard practice, but no pb adding this after
the current build problem is fixed.

Wow, yes, it should be the 'default'. The single statement
set(CMAKE_DEBUG_POSTFIX "d" ...), as in -
https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/CMakeLists.txt#l70
adds the 'd' to **all** libraries built, but for
each 'ADD_EXECUTABLE', it **must** be added specifically...
has been that way for a long, LONG time... sadly...

But you are right, this is **nothing** about Debug
versions, and the associated *.pdb files in Windows...

Post by Florent Rougon
What I meant is that 'fgrcc' needs SimGear to run, ...

Only, ONLY, if we are using a SHARED library... a DLL!

This has never been the case in Windows, otherwise the
'nightly' build, and install, would need to include
SimGear DLLs in the installer... it could...

I do not often download and run nightlies, since I can
build my own, but I note the last 2017.2.0 nightly, and
every previous, did **not** include SG DLLS...

And just for fun, I just downloaded the FlightGear-2017.2.1,exe,
release, all 1.5 GB, and it does **not** include SG DLLS...

There are many DLLS included, most notably zlib.dll, and
many osg dlls, Qt5 dlls, etc... but no SG...

Now maybe this is the **new** case, and then sorry for the
noise... but I always thought Windows 'fgfs.exe', and
thus 'fgrcc.exe', would be using the 'static' SimGear
libraries in Windows...

Maybe I am **very** wrong! Sorry for that...

Please confirm...

Post by Florent Rougon
-DMSVC_3RDPARTY_ROOT:PATH="G:\jenkins\workspace\FlightGear-Win"

If you do not see a problem with that, then unsure what
I can add...

If indeed "G:\jenkins\workspace\FlightGear-Win\3rdParty.x64\bin",
assuming now MSVC_3RDPARTY_DIR contains just '3rdParty.x64',
contains 'zlib.dll', which it seems to, then I am out of ideas...
sorry...

But am sure the error message is about running 'fgrcc'
during the build... not something else... but maybe I
am real **wrong**... sorry...

Just trying to help... and explore... thanks...

Regards,
Geoff.

[Florent Rougon]

Hi,

Post by Geoff McLane
Only, ONLY, if we are using a SHARED library... a DLL!
This has never been the case in Windows, otherwise the
'nightly' build, and install, would need to include
SimGear DLLs in the installer... it could...
I do not often download and run nightlies, since I can
build my own, but I note the last 2017.2.0 nightly, and
every previous, did **not** include SG DLLS...

SimGear-Win on jenkins seems to build static libs indeed:

-- Library building mode: STATIC LIBRARIES
(http://build.flightgear.org:8080/job/SimGear-Win/lastSuccessfulBuild/consoleText)

Post by Geoff McLane
And just for fun, I just downloaded the FlightGear-2017.2.1,exe,
release, all 1.5 GB, and it does **not** include SG DLLS...
There are many DLLS included, most notably zlib.dll, and
many osg dlls, Qt5 dlls, etc... but no SG...

Right, I see .lib files for SimGear in
http://build.flightgear.org:8080/job/FlightGear-Win/ws/install/msvc140/SimGear/
but no DLL.

Post by Geoff McLane
Now maybe this is the **new** case, and then sorry for the
noise... but I always thought Windows 'fgfs.exe', and
thus 'fgrcc.exe', would be using the 'static' SimGear
libraries in Windows...
Maybe I am **very** wrong! Sorry for that...
Please confirm...

I'm (by far) not the best person for this, but it *seems* to be the
case.

Post by Geoff McLane

Post by Florent Rougon
-DMSVC_3RDPARTY_ROOT:PATH="G:\jenkins\workspace\FlightGear-Win"

If you do not see a problem with that, then unsure what
I can add...
If indeed "G:\jenkins\workspace\FlightGear-Win\3rdParty.x64\bin",
assuming now MSVC_3RDPARTY_DIR contains just '3rdParty.x64',
contains 'zlib.dll', which it seems to, then I am out of ideas...
sorry...

It can be seen on the jenkins worskpace in the expected place:

http://build.flightgear.org:8080/job/FlightGear-Win/ws/3rdParty/bin/

(even zlibd.dll too)

Post by Geoff McLane
But am sure the error message is about running 'fgrcc'
during the build... not something else... but maybe I
am real **wrong**... sorry...
Just trying to help... and explore... thanks...

Thank you. I believe the problem may be due to a configuration error on
jenkins. If you look at:

http://build.flightgear.org:8080/job/FlightGear-Win/lastFailedBuild/console

you'll see:

G:\Jenkins\workspace\FlightGear-Win\build32>cmake ..\source -G "Visual Studio 14 2015" -DENABLE_PROFILE=OFF -DBOOST_INCLUDEDIR:PATH="G:\jenkins\workspace\FlightGear-Win" -DMSVC_3RDPARTY_ROOT:PATH="G:\jenkins\workspace\FlightGear-Win" -DCMAKE_PREFIX_PATH:PATH="D:\Qt\5.6\msvc2015;G:\jenkins\workspace\FlightGear-Win/install/msvc140/SimGear" -DCMAKE_INSTALL_PREFIX:PATH="G:\jenkins\workspace\FlightGear-Win/install/msvc140/FlightGear"
CMAKE Build type:
-- Setting build type to 'Debug' as none was specified.

[...]

-- Generating done
-- Build files have been written to: G:/Jenkins/workspace/FlightGear-Win/build32

G:\Jenkins\workspace\FlightGear-Win\build32>cmake --build . --config RelWithDebInfo --target INSTALL
Microsoft (R) Build Engine version 14.0.24730.2
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 6/13/2017 9:45:57 AM.

[...]

but then, inspecting

http://build.flightgear.org:8080/job/FlightGear-Win/ws/build32/src/Main/fgfs.vcxproj

I found:

<CustomBuild Include="G:\Jenkins\workspace\FlightGear-Win\build32\CMakeFiles\544ab9e568fafd543a40b06b00b7f3bb\FlightGear-resources.cxx.rule">
<Message Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">Generating ../EmbeddedResources/FlightGear-resources.cxx, ../EmbeddedResources/FlightGear-resources.hxx</Message>
<Command Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">setlocal
set PATH=G:/jenkins/workspace/FlightGear-Win/3rdParty/bin;%PATH%
..\EmbeddedResources\Debug\fgrcc.exe --root=G:/Jenkins/workspace/FlightGear-Win/source --output-cpp-file=G:/Jenkins/workspace/FlightGear-Win/build32/src/EmbeddedResources/FlightGear-resources.cxx --init-func-name=initFlightGearEmbeddedResources --output-header-file=G:/Jenkins/workspace/FlightGear-Win/build32/src/EmbeddedResources/FlightGear-resources.hxx --output-header-identifier=_FG_FLIGHTGEAR_EMBEDDED_RESOURCES G:/Jenkins/workspace/FlightGear-Win/source/src/EmbeddedResources/FlightGear-resources.xml
if %errorlevel% neq 0 goto :cmEnd

[...]

The command is correct, except that it is trying to run
..\EmbeddedResources\Debug\fgrcc.exe, which does not exist!
The directory:

http://build.flightgear.org:8080/job/FlightGear-Win/ws/build32/src/EmbeddedResources/

contains RelWithDebInfo/fgrcc.exe, but it doesn't even contain a Debug
subdir (since the actual build was started with
'cmake --build . --config RelWithDebInfo --target INSTALL').

I believe that if the above 'cmake ..\source ...' command were fixed not
to implicitly choose the 'Debug' build type, the problem would probably
go away.

Anyone knowing the Windows jenkins setup, please?

Thanks

[j***@kdab.com]

I thought it was common knowledge, but perhaps not: Simgear shared mode
(DLLs) is not supported on Windows - we always build static.

(I did some work recently towards it but it means annotating a huge
amount of stuff with SG_EXPORT, so don't wait for it)

I will be back at home tomorrow, and check the Jenkins config then, but
I don't think it is seriously amiss. Florent your existing change looks
correct + sufficient to me.

Kind regards,
James

[Florent Rougon]

Hi,

I thought it was common knowledge, but perhaps not: Simgear shared mode (DLLs)
is not supported on Windows - we always build static.
(I did some work recently towards it but it means annotating a huge amount of
stuff with SG_EXPORT, so don't wait for it)

Roger

I will be back at home tomorrow, and check the Jenkins config then, but I
don't think it is seriously amiss. Florent your existing change looks correct
+ sufficient to me.

You may well be right about the Jenkins config, because looking again at the
same
<http://build.flightgear.org:8080/job/FlightGear-Win/ws/build32/src/Main/fgfs.vcxproj>,
I see the fgrcc invocation is also present (duplicated) for other build
types: Release, MinSizeRel, and surely RelWithDebInfo:

<Command Condition="'$(Configuration)|$(Platform)'=='RelWithDebInfo|Win32'">setlocal
set PATH=G:/jenkins/workspace/FlightGear-Win/3rdParty/bin;%PATH%
..\EmbeddedResources\RelWithDebInfo\fgrcc.exe --root=G:/Jenkins/workspace/FlightGear-Win/source --output-cpp-file=G:/Jenkins/workspace/FlightGear-Win/build32/src/EmbeddedResources/FlightGear-resources.cxx --init-func-name=initFlightGearEmbeddedResources --output-header-file=G:/Jenkins/workspace/FlightGear-Win/build32/src/EmbeddedResources/FlightGear-resources.hxx --output-header-identifier=_FG_FLIGHTGEAR_EMBEDDED_RESOURCES G:/Jenkins/workspace/FlightGear-Win/source/src/EmbeddedResources/FlightGear-resources.xml

So, if this one is chosen, there must be some other explanation. I saw
that
<https://cmake.org/cmake/help/latest/command/add_custom_command.html>
recommends using the VERBATIM option:

VERBATIM
All arguments to the commands will be escaped properly for the build
tool so that the invoked command receives each argument unchanged.
Note that one level of escapes is still used by the CMake language
processor before add_custom_command even sees the arguments. Use of
VERBATIM is recommended as it enables correct behavior. When
VERBATIM is not given the behavior is platform specific because
there is no protection of tool-specific special characters.

It's probably a good idea to add (seems already supported by CMake 3.0),
however I don't think it has any chance to solve the problem at hand.

I don't see any way to put this add_custom_command() thing in verbose
mode, unfortunately. However, the 'make' command can be run with
VERBOSE=1, which would maybe tell us more. After converting all files
from
http://build.flightgear.org:8080/job/FlightGear-Win/ws/build32/src/Main/fgfs.dir/RelWithDebInfo/fgfs.tlog/
to UTF-8, I found only one to contain the string fgrcc (with 'grep -i'),
namely custombuild.command.1.tlog. It contains the generated script
lines apparently without any separation between them (?!), and has
RelWithDebInfo\fgrcc.exe inside.

^G:\JENKINS\WORKSPACE\FLIGHTGEAR-WIN\SOURCE\SRC\MAIN\CMAKELISTS.TXT
setlocalset PATH=G:/jenkins/workspace/FlightGear-Win/3rdParty/bin;%PATH%"d:\Program Files (x86)\CMake\bin\cmake.exe" -HG:/Jenkins/workspace/FlightGear-Win/source -BG:/Jenkins/workspace/FlightGear-Win/build32 --check-stamp-file G:\Jenkins\workspace\FlightGear-Win\build32\src\Main\CMakeFiles\generate.stampif %errorlevel% neq 0 goto :cmEnd:cmEndendlocal & call :cmErrorLevel %errorlevel% & goto :cmDone:cmErrorLevelexit /b %1:cmDoneif %errorlevel% neq 0 goto :VCEnd
^G:\JENKINS\WORKSPACE\FLIGHTGEAR-WIN\BUILD32\CMAKEFILES\544AB9E568FAFD543A40B06B00B7F3BB\FLIGHTGEAR-RESOURCES.CXX.RULE
setlocalset PATH=G:/jenkins/workspace/FlightGear-Win/3rdParty/bin;%PATH%..\EmbeddedResources\RelWithDebInfo\fgrcc.exe --root=G:/Jenkins/workspace/FlightGear-Win/source --output-cpp-file=...

Thanks for looking into this mystery!

[Geoff McLane]

Hi,

On 14/06/17 12:03, Florent Rougon wrote:
On 14/06/17 12:48, ***@kdab.com wrote:
On 14/06/17 15:35, Florent Rougon wrote:

Ok, as James says, Simgear is static in Windows...
without a lot of work adding __declspec(), aka say
SG_EXPORT, all over the place, although it can also
be done with a *.def file...

While you first pointed out -
...\build32\src\EmbeddedResources\Debug\fgrcc.exe
then as you inspect closely, there are normally 4
configurations -
Debug, Release, MinSizeRel, and RelWithDebInfo

Since it seems it is building RelWithDebInfo -
cmake --build . --config RelWithDebInfo --target INSTALL
then it should be using -
...\build32\src\EmbeddedResources\RelWithDebInfo\fgrcc.exe
which is there...

I too can not yet see what went wrong running it...
other than for some reason it still can not find
zlib.dll... but it does seem the PATH is set correctly...

But assume James knows the config he setup, so am sure
it will soon be fixed...

Regards,
Geoff.

[James Turner]

Me too of course... I just feel a bit powerless with this failing build
giving no useful error message (and limited resources).

My local Windows build works fine, so it’s ‘just’ a Jenkins issue, will take a look now.

Let’s focus on the limited subset we need to actually get working for now, not
worry about compliance with the full-spec.

Okay, will do that, then.

My action / key-binding changes are close to working, will try to finish them this weekend. They will really benefit from the translation changes, but it might slightly complicate your API:

- actions have a unique id: ‘toggle-parking-brake’ or ‘engage-ap-heading-mode’

- based on this I expect to lookup ideally both a name and a description. I guess we do this by have some categories:

get_locale()->getLocalizedString(actionid, “action-name”)

get_locale()->getLocalizedString(actionid, “action-description”)

?

As a complication, some actions are defined as type ‘toggle’, and I guess ideally the name would maybe change based on the toggle state:

if (action->toggleState())
get_locale()->getLocalizedString(actionid + “-on", “action-name”)
else
get_locale()->getLocalizedString(actionid + “-off", “action-name”)

This is to allow action items like ‘enter full-screen mode’ to become ‘exit full-screen mode’ and similar to be done nicely.

Does this sound feasible? I’m not sure how we generate the list of action-ids, so that translations can find them? They will be defined in FG_DATA/actions.xml but aircraft might add their own in special situations, I would hope that’s rare though. (They will work much better if there are defined centrally, and aircraft simply hook into them but keep the same ID, which is supported
) I guess we can’t escape aircraft needing to supply translations in some cases however, Thorsten also asked about aircraft-specific startup tips
.

Kind regards,
James

[Florent Rougon]

Hi,

Sorry about the delays...

Post by James Turner
My action / key-binding changes are close to working, will try to
finish them this weekend. They will really benefit from the
- actions have a unique id: ‘toggle-parking-brake’ or ‘engage-ap-heading-mode’
- based on this I expect to lookup ideally both a name and a
get_locale()->getLocalizedString(actionid, “action-name”)
get_locale()->getLocalizedString(actionid, “action-description”)
?
if (action->toggleState())
get_locale()->getLocalizedString(actionid + “-on", “action-name”)
else
get_locale()->getLocalizedString(actionid + “-off", “action-name”)
This is to allow action items like ‘enter full-screen mode’ to become ‘exit full-screen mode’ and similar to be done nicely.
Does this sound feasible? I’m not sure how we generate the list of action-ids, so that translations can find them? They will be defined in FG_DATA/actions.xml but aircraft might add their own in special situations, I would hope that’s rare though. (They will work much better if there are defined centrally, and aircraft simply hook into them but keep the same ID, which is supported
) I guess we can’t escape aircraft needing to supply translations in some cases however, Thorsten also asked about aircraft-specific startup tips
.

It's difficult for me to answer the API questions without a clear
picture of how the translatable strings are going to be extracted and
merged.

First, to be clear, since you wrote “your API”, the
EmbeddedResourceManager locale feature was not meant to select
translatable strings according to the locale (I don't know if that is
what you had in mind, but otherwise I don't know what you meant by “your
API” [i.e., mine]). This feature mimics the corresponding one in Qt's
rcc tool and associated format: it selects a *whole* resource based on
the locale (and of course based on the resource virtual path).

The example for this feature given in Qt's documentation of the RCC
format is a locale-dependent icon. Another possibility would be a README
file (or XML) translated in several languages. But it doesn't address
the problem of detecting outdated translations. The only thing it does
is select the “best” version of a resource according to the locale
(e.g., "fr_FR", then if not found "fr", then if still not found the
default locale ""). But if this localized resource is outdated wrt the
English version, that's too bad.

Yes, in theory a short string (thinking of typical localized messages of
a program) can be registered and retrieved the same as a README file,
but the infrastructure wasn't designed for this, and I'm not sure it's a
good fit. The locale fallback algorithm is rather simple and can be
copy-pasted to a more specialized infrastructure if that's really the
thing... which I doubt. :)

More to the problems you evoked: we need to know how translatable
strings will be extracted and merged. For C++ files, there are usually
already-written tools that extract function calls like _(), tr() or
tr_noop(). I think you know that. Function names depend on the
framework, the last one I used was gettext, it supports several parsed
languages (C, Python...) and the special function names can be chosen
via cmdline args, including whether they take additional parameters for
plural forms and things like that---this is the xgettext program, but
it works with .po, not XLIFF AFAIK.

My main concern here is that you seem to want translatable strings in FG
XML files. How do we extract them and merge them with existing
translations? Extracting can be done by custom parsing of the XML file,
of course, but then you have to detect fuzzy strings (already-translated
strings whose English version has been updated) and those that have
disappeared. This doesn't sound trivial without a good library or
special-purpose tool (for XLIFF).

The other things you mentioned (additional string-selection “knobs”) can
probably be addressed with context attributes of the XLIFF format, but
one has to check if all tools we'll need properly deal with such
attributes the way they are used. I'm saying this in particular because
the main motivation behind XLIFF 2.0 seems to be that XLIFF 1.2 was too
complex and sometimes ambiguous, with the result that “the majority of
XLIFF 1.2 implementations today [on Aug 27, 2014] are not complete”[1].

Attaching the script I mentioned in private (plain text output just to
show that the input works). It's in Python 3.

Regards

[1] http://info.moravia.com/blog/bid/354057/What-s-So-Sexy-About-XLIFF-2-0

[Florent Rougon]

Post by Florent Rougon
Yes, in theory a short string (thinking of typical localized messages of
a program) can be registered and retrieved the same as a README file,
but the infrastructure wasn't designed for this, and I'm not sure it's a
good fit. The locale fallback algorithm is rather simple and can be
copy-pasted to a more specialized infrastructure if that's really the
thing... which I doubt. :)

I replied to this part with more reflexion in the appropriate thread:

https://sourceforge.net/p/flightgear/mailman/message/35907360/

[Florent Rougon]

Post by James Turner
Unfortunately, this has broken my Windows build setup, because zlib.dll is not
in the PATH, and hence fgrcc fails to run.

By the way, I find it a bit weird that the problem comes from zlib.dll,
because fgrcc doesn't use zlib *directly*: it uses SimGear functions
which themselves rely on zlib. So, unless you have to manually arrange
the PATH for all transitive runtime deps, having a working SimGear for
fgrcc should be enough. But linking is often strange...

Regards