Am Montag, 7. August 2017 um 19:32:15, schrieb Scott Kostyshak
<skost...@lyx.org>
> On Mon, Aug 07, 2017 at 09:36:34AM +0200, Kornel Benko wrote:
> > Am Sonntag, 6. August 2017 um 21:55:57, schrieb Scott Kostyshak
> > <skost...@lyx.org>
> > > On Sun, Aug 06, 2017 at 10:17:16AM +0200, Kornel Benko wrote:
> > >
> > > > This should not happen. The check for the need of reconfiguration is
> > > > done at LyX.cpp:1053
> > > > bool LyX::queryUserLyXDir(bool explicit_userdir)
> > > > which is called at LyX.cpp:921.
> > > > This call is guarded with fileLock(lock_file.c_str());
> > > > And the reconfiguration is done in the same guard.
> > > > {
> > > > string const lock_file =
> > > > package().getConfigureLockName();
> > > > int fd = fileLock(lock_file.c_str());
> > > >
> > > > if (queryUserLyXDir(package().explicit_user_support()))
> > > > {
> > > > package().reconfigureUserLyXDir("");
> > > > // Now the user directory is present on first
> > > > start.
> > > > initTemplatePath();
> > > > }
> > > > fileUnlock(fd, lock_file.c_str());
> > > > }
> > >
> > > Thanks for that clue. Attached is a patch that I used for debugging to
> > > figure
> > > out what is calling configure.py. Running the parallel ctests (with many
> > > jobs)
> > > with the patch applied, gave the following files on my desktop:
> > >
> > > callingconfig_47059
> > > configurepy_46743_ppid46728
> > > configurepy_47073_ppid47059
> > >
> > > Already we can see that the LyX binary calls configure.py once (assuming
> > > that
> > > the LyX binary can only call it from that function), and that
> > > configure.py was
> > > called twice.
> > >
> > > $ cat configurepy_46743_ppid46728
> > > command_ is /usr/bin/python3 -tt
> > > /home/scott/lyxbuilds/master/repo/lib/scripts/../configure.py
> > > --binary-dir=/home/scott/lyxbuilds/master/CMakeBuild/bin/
> > > pcommand_ is /usr/bin/cmake
> > > -DLYX_TESTS_USERDIR=/home/scott/lyxbuilds/master/CMakeBuild/Testing/.lyx
> > > -DLYX_USERDIR_VER=LYX_USERDIR_23x
> > > -DLYX_PYTHON_EXECUTABLE=/usr/bin/python3
> > > -DPY_SCRIPT=/home/scott/lyxbuilds/master/repo/src/tex2lyx/test/runtests.py
> > > -DTEX2LYX_EXE=/home/scott/lyxbuilds/master/CMakeBuild/bin/tex2lyx
> > > -DSCRIPT_DIR=/home/scott/lyxbuilds/master/repo/lib/scripts
> > > -DWORKDIR=/home/scott/lyxbuilds/master/CMakeBuild/src/tex2lyx/test
> > > -DTESTFILE=test.ltx -P
> > > /home/scott/lyxbuilds/master/repo/src/tex2lyx/test/runtests.cmake
> > >
> > > $ cat configurepy_47073_ppid47059
> > > command_ is python -tt
> > > /home/scott/lyxbuilds/master/repo/lib/configure.py
> > > --binary-dir=/home/scott/lyxbuilds/master/CMakeBuild/bin/
> > > pcommand_ is /home/scott/lyxbuilds/master/CMakeBuild/bin/lyx -batch
> > > -userdir /home/scott/lyxbuilds/master/CMakeBuild/Testing/.lyx
> > > /home/scott/lyxbuilds/master/repo/autotests/export/MissingEndLayoutBetweenTables.lyx
> > >
> > > I'm not sure how to proceed to make _configure_needed more robust inside
> > > runtests.cmake.
> > >
> > > Is an alternative to make configure.py thread safe (is this a correct use
> > > of the
> > > term?) itself by having a lock inside of it?
> >
> > Searching for calls to configGileNeedsUpdate() I came across the file
> > tex2lyx.cpp.
> > The test there is not complete compared to the one in LyX.cpp, see patch
> > 001-tex2lyx.cpp.patch.
> >
> > In src/support/filetools.cpp, we could check if the locking was successful.
> >
> > I'm running the tests now, we may have some luck.
(I meant here export tests and probably also mixed up some things)
> Would this fix the issue coming from runtests.cmake? Let me know if you want
> me
> to test a patch.
Don't know. These tests (e.g. tex2lyx tests) should be running sequentially
anyway, at least that was the intent,
and I did not observe parallel runs yet.
> Scott
Kornel
Kornel
signature.asc
Description: This is a digitally signed message part.
