Stephan Witt wrote: > Am 25.11.2013 um 13:01 schrieb Vincent van Ravesteijn <v...@lyx.org>: > >> The problem is that the commit is touching very essential code. If >> something goes wrong LyX becomes pretty much unusable (e.g. if configure >> isn't run anymore). We can never be sure that there is no platform out >> there which causes this code to fail. I'm also not sure whether the code >> is fixing a bug, or facilitating some tests ? >> >> IMO, the fact that the code is between #ifdef's doesn't make it portable. > > IMHO, you are changing the rules. There is plenty of non-portable code in > LyX if this would be the rule.
I don't agree either. ifdefs are fine in many cases, e.g. if you need to work around a bug that only exists on one specific platform, or if you are dealing with a feature that exists only on one platform (e.g. the linkback stuff). However, in this particular case, the code has a problem: support::fileLock() and support::fileUnlock() behave _very_ differently depending on the platform, although the underlying concept (locking files) works fine on any platform supported by LyX. I don't care if it is called nonportable or something else, but it is a problem, since on windows the functions do not do what their names suggest. > I think, we should discuss the meaning of "portable code" then. > > Another move to improve the situation would be to present a code fragment > or a pointer to some example code how to solve the locking issue on > Windows. I already gave pointers to MSDN page explaining the relevant windows API function to use. I deliberately did not search for code fragments, because I am too lazy to dig into the nasty details of this API function, and I did not want to check the copyright, and this needs to be done before any code can be used. Also, Tommaso mentioned boost, which appearantly has a working solution, so I do not really understand why we need to reinvent the wheel. To answer Kornels question from another message: IIRC the agreement is to use as little boost as possible (e.g. if an equivalent qt solution exists qt should be preferred), but IMHO in case of file locking the benefits of using boost outweigh the drawbacks. Georg
