Re: trunk: lyx2lyx problem
Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico On Tue, Sep 05, 2006 at 06:46:23PM +0200, Enrico Forestieri Enrico wrote: Anyway, if you want to take into account that someone could actually cross-compile to mingw using cygwin, the attached patch fixes this issue. Enrico No, please don't apply this patch as it would also affect a Enrico cygwin build. Both $host_os and $build_os should be checked Enrico and it really becomes cumbersome. Let's keep it as it is now, then. JMarc
Re: trunk: lyx2lyx problem
On Wed, Sep 06, 2006 at 10:08:04AM +0200, Jean-Marc Lasgouttes wrote: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico On Tue, Sep 05, 2006 at 06:46:23PM +0200, Enrico Forestieri Enrico wrote: Anyway, if you want to take into account that someone could actually cross-compile to mingw using cygwin, the attached patch fixes this issue. Enrico No, please don't apply this patch as it would also affect a Enrico cygwin build. Both $host_os and $build_os should be checked Enrico and it really becomes cumbersome. Let's keep it as it is now, then. Agreed. Cross-compiling LyX/Win from another platform is not going to work because of this MSYS_AC_CANONICAL_PATH thing, but this is not a big a problem, I think. -- Enrico
Re: trunk: lyx2lyx problem
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> On Tue, Sep 05, 2006 at 06:46:23PM +0200, Enrico Forestieri Enrico> wrote: >> Anyway, if you want to take into account that someone could >> actually cross-compile to mingw using cygwin, the attached patch >> fixes this issue. Enrico> No, please don't apply this patch as it would also affect a Enrico> cygwin build. Both $host_os and $build_os should be checked Enrico> and it really becomes cumbersome. Let's keep it as it is now, then. JMarc
Re: trunk: lyx2lyx problem
On Wed, Sep 06, 2006 at 10:08:04AM +0200, Jean-Marc Lasgouttes wrote: > > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: > > Enrico> On Tue, Sep 05, 2006 at 06:46:23PM +0200, Enrico Forestieri > Enrico> wrote: > >> Anyway, if you want to take into account that someone could > >> actually cross-compile to mingw using cygwin, the attached patch > >> fixes this issue. > > Enrico> No, please don't apply this patch as it would also affect a > Enrico> cygwin build. Both $host_os and $build_os should be checked > Enrico> and it really becomes cumbersome. > > Let's keep it as it is now, then. Agreed. Cross-compiling LyX/Win from another platform is not going to work because of this MSYS_AC_CANONICAL_PATH thing, but this is not a big a problem, I think. -- Enrico
Re: trunk: lyx2lyx problem
Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico Look at package.C.in: Enrico This is not going to work when packaging is windows or Enrico macosx... Hmm, what is not going to work? the build support dir is BINDIR/../lib always, isn't it? But I do not think this is the part that fails. Could you show me the output of lyx -dbg init again? I do not remember what it was. JMarc
Re: trunk: lyx2lyx problem
On Mon, Sep 04, 2006 at 11:08:31AM +0200, Jean-Marc Lasgouttes wrote: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico IIRC, the build_support dir is not correctly spotted in a Enrico native Windows build. Run lyx -dbg init to check it. It would be nice to investigate this. Sorry for the noise, it was my fault :( In the configure script there is the code brought in by AC_DEFUN([MSYS_AC_CANONICAL_PATH]... that transforms every path into windows style when using a mingw environment, but into posix style when using a cygwin environment. I am using a cygwin environment even for building a native LyX and thus LYX_ABS_TOP_SRCDIR, LYX_ABS_INSTALLED_LOCALEDIR, and LYX_ABS_INSTALLED_DATADIR are affected by the code above. I was already aware of the last two, but was missing LYX_ABS_TOP_SRCDIR, which was being hardcoded in posix style into package.C. Once taken care of that (a simple call to cygpath in the configure script does it) everything is right and running LyX in place works also for a native Windows build. Sorry again for the mishap. -- Enrico
Re: trunk: lyx2lyx problem
On Tue, Sep 05, 2006 at 12:29:39PM +0200, Jean-Marc Lasgouttes wrote: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico Look at package.C.in: Enrico This is not going to work when packaging is windows or Enrico macosx... Hmm, what is not going to work? the build support dir is BINDIR/../lib always, isn't it? But I do not think this is the part that fails. Could you show me the output of lyx -dbg init again? I do not remember what it was. Sorry JMarc. It was a while from when I built a native Windows version of LyX. From my memory, I could not run it in place, but never bothered to invesigate the thing. I had a cursory glance at package.C and thought that the problem was due to the exchange of lib and Resources but, just after I wrote the above, I had already realized that it was nonsense. So i built again a native Windows LyX and spotted the problem. It was my fault. See my other post. -- Enrico
Re: trunk: lyx2lyx problem
Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico I was already aware of the last two, but was missing Enrico LYX_ABS_TOP_SRCDIR, which was being hardcoded in posix style Enrico into package.C. Once taken care of that (a simple call to Enrico cygpath in the configure script does it) everything is right Enrico and running LyX in place works also for a native Windows Enrico build. Does this mean there some patch I should apply? JMarc
Re: trunk: lyx2lyx problem
On Tue, Sep 05, 2006 at 03:49:12PM +0200, Jean-Marc Lasgouttes wrote: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico I was already aware of the last two, but was missing Enrico LYX_ABS_TOP_SRCDIR, which was being hardcoded in posix style Enrico into package.C. Once taken care of that (a simple call to Enrico cygpath in the configure script does it) everything is right Enrico and running LyX in place works also for a native Windows Enrico build. Does this mean there some patch I should apply? I don't think so. When using msys/mingw, the right thing is done. I need to patch configure because I am actually cross-compiling to mingw using the cygwin compiler. In this case I have to do sed ' # Set top_src, locale, and data dir in mixed rather than posix format /^ *LYX_ABS_TOP_SRCDIR/s/\(^ *\)/\1ac_val=`cygpath -m \\$ac_val\`\n\1/ /^ *LYX_ABS_INSTALLED/s/\(^ *\)/\1ac_val=`cygpath -m \\$ac_val\`\n\1/' \ configure configure-win32 before calling configure-win32 --host=i686-pc-mingw32 --build=i686-pc-cygwin ... Anyway, if you want to take into account that someone could actually cross-compile to mingw using cygwin, the attached patch fixes this issue. -- Enrico --- config/lyxinclude.m4.orig 2006-08-17 17:53:26.0 +0200 +++ config/lyxinclude.m42006-09-05 18:26:26.0 +0200 @@ -695,6 +695,9 @@ done ac_dir=`echo $ac_dir | sed 's?^[[./]]*??'` ac_val=`echo $ac_val | sed 's?/*$[]??'` + case $build_os in + cygwin*) ac_val=`cygpath -m $ac_val`;; + esac $1=`echo $2 | sed s?^[[./]]*$ac_dir/*?$ac_val/?' s?/*$[]??'` ])
Re: trunk: lyx2lyx problem
On Tue, Sep 05, 2006 at 06:46:23PM +0200, Enrico Forestieri wrote: Anyway, if you want to take into account that someone could actually cross-compile to mingw using cygwin, the attached patch fixes this issue. No, please don't apply this patch as it would also affect a cygwin build. Both $host_os and $build_os should be checked and it really becomes cumbersome. -- Enrico
Re: trunk: lyx2lyx problem
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> Look at package.C.in: Enrico> This is not going to work when packaging is windows or Enrico> macosx... Hmm, what is not going to work? the build support dir is BINDIR/../lib always, isn't it? But I do not think this is the part that fails. Could you show me the output of lyx -dbg init again? I do not remember what it was. JMarc
Re: trunk: lyx2lyx problem
On Mon, Sep 04, 2006 at 11:08:31AM +0200, Jean-Marc Lasgouttes wrote: > > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: > > Enrico> IIRC, the build_support dir is not correctly spotted in a > Enrico> native Windows build. Run "lyx -dbg init" to check it. > > It would be nice to investigate this. Sorry for the noise, it was my fault :( In the configure script there is the code brought in by AC_DEFUN([MSYS_AC_CANONICAL_PATH]... that transforms every path into windows style when using a mingw environment, but into posix style when using a cygwin environment. I am using a cygwin environment even for building a native LyX and thus LYX_ABS_TOP_SRCDIR, LYX_ABS_INSTALLED_LOCALEDIR, and LYX_ABS_INSTALLED_DATADIR are affected by the code above. I was already aware of the last two, but was missing LYX_ABS_TOP_SRCDIR, which was being hardcoded in posix style into package.C. Once taken care of that (a simple call to cygpath in the configure script does it) everything is right and running LyX in place works also for a native Windows build. Sorry again for the mishap. -- Enrico
Re: trunk: lyx2lyx problem
On Tue, Sep 05, 2006 at 12:29:39PM +0200, Jean-Marc Lasgouttes wrote: > > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: > > Enrico> Look at package.C.in: > > Enrico> This is not going to work when packaging is windows or > Enrico> macosx... > > Hmm, what is not going to work? the build support dir is BINDIR/../lib > always, isn't it? > > But I do not think this is the part that fails. Could you show me the > output of lyx -dbg init again? I do not remember what it was. Sorry JMarc. It was a while from when I built a native Windows version of LyX. From my memory, I could not run it in place, but never bothered to invesigate the thing. I had a cursory glance at package.C and thought that the problem was due to the exchange of "lib" and "Resources" but, just after I wrote the above, I had already realized that it was nonsense. So i built again a native Windows LyX and spotted the problem. It was my fault. See my other post. -- Enrico
Re: trunk: lyx2lyx problem
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> I was already aware of the last two, but was missing Enrico> LYX_ABS_TOP_SRCDIR, which was being hardcoded in posix style Enrico> into package.C. Once taken care of that (a simple call to Enrico> cygpath in the configure script does it) everything is right Enrico> and running LyX in place works also for a native Windows Enrico> build. Does this mean there some patch I should apply? JMarc
Re: trunk: lyx2lyx problem
On Tue, Sep 05, 2006 at 03:49:12PM +0200, Jean-Marc Lasgouttes wrote: > > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: > > Enrico> I was already aware of the last two, but was missing > Enrico> LYX_ABS_TOP_SRCDIR, which was being hardcoded in posix style > Enrico> into package.C. Once taken care of that (a simple call to > Enrico> cygpath in the configure script does it) everything is right > Enrico> and running LyX in place works also for a native Windows > Enrico> build. > > Does this mean there some patch I should apply? I don't think so. When using msys/mingw, the right thing is done. I need to patch configure because I am actually cross-compiling to mingw using the cygwin compiler. In this case I have to do sed ' # Set top_src, locale, and data dir in mixed rather than posix format /^ *LYX_ABS_TOP_SRCDIR/s/\(^ *\)/\1ac_val=`cygpath -m \"\$ac_val\"`\n\1/ /^ *LYX_ABS_INSTALLED/s/\(^ *\)/\1ac_val=`cygpath -m \"\$ac_val\"`\n\1/' \ configure > configure-win32 before calling configure-win32 --host=i686-pc-mingw32 --build=i686-pc-cygwin ... Anyway, if you want to take into account that someone could actually cross-compile to mingw using cygwin, the attached patch fixes this issue. -- Enrico --- config/lyxinclude.m4.orig 2006-08-17 17:53:26.0 +0200 +++ config/lyxinclude.m42006-09-05 18:26:26.0 +0200 @@ -695,6 +695,9 @@ done ac_dir=`echo "$ac_dir" | sed 's?^[[./]]*??'` ac_val=`echo "$ac_val" | sed 's?/*$[]??'` + case $build_os in + cygwin*) ac_val=`cygpath -m "$ac_val"`;; + esac $1=`echo "$2" | sed "s?^[[./]]*$ac_dir/*?$ac_val/?"' s?/*$[]??'` ])
Re: trunk: lyx2lyx problem
On Tue, Sep 05, 2006 at 06:46:23PM +0200, Enrico Forestieri wrote: > Anyway, if you want to take into account that someone could actually > cross-compile to mingw using cygwin, the attached patch fixes this issue. No, please don't apply this patch as it would also affect a cygwin build. Both $host_os and $build_os should be checked and it really becomes cumbersome. -- Enrico
Re: trunk: lyx2lyx problem
Bo Peng wrote: When using autotools lyx2lyx_version.py is generated in lib/lyx2lyx under the build directory. If you run lyx in place, this directory is also taken into account and thus lyx2lyx_version.py is found: I agree that this is convenient, but it is against the idea of source/build separation. Right now, a scons build will not touch or create any file (including config.h) in the source directory. I am not sure it is a good idea to change it. For scons, I'd say keep it like it is now. CMake needs to so something about that... Abdel.
Re: trunk: lyx2lyx problem
Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico IIRC, the build_support dir is not correctly spotted in a Enrico native Windows build. Run lyx -dbg init to check it. It would be nice to investigate this. JMarc
Re: trunk: lyx2lyx problem
On Sun, Sep 03, 2006 at 11:05:53PM -0500, Bo Peng wrote: When using autotools lyx2lyx_version.py is generated in lib/lyx2lyx under the build directory. If you run lyx in place, this directory is also taken into account and thus lyx2lyx_version.py is found: I agree that this is convenient, but it is against the idea of source/build separation. Right now, a scons build will not touch or create any file (including config.h) in the source directory. I am not sure it is a good idea to change it. The source directory is not touched at all. A lib/lyx2lyx dir is created in the build directory and lyx2lyx_version.py is put there. This directory is then added to the libdir search path when it is detected that lyx is run in place. -- Enrico
Re: trunk: lyx2lyx problem
On Mon, Sep 04, 2006 at 11:08:31AM +0200, Jean-Marc Lasgouttes wrote:
Enrico == Enrico Forestieri [EMAIL PROTECTED] writes:
Enrico IIRC, the build_support dir is not correctly spotted in a
Enrico native Windows build. Run lyx -dbg init to check it.
It would be nice to investigate this.
Look at package.C.in:
std::string const
get_build_support_dir(std::string const binary_dir,
exe_build_dir_to_top_build_dir top_build_dir_location)
{
string indirection;
switch (top_build_dir_location) {
case top_build_dir_is_one_level_up:
indirection = ../lib;
break;
case top_build_dir_is_two_levels_up:
indirection = ../../lib;
break;
}
return normalizePath(addPath(binary_dir, indirection));
}
This is not going to work when packaging is windows or macosx...
--
Enrico
Re: trunk: lyx2lyx problem
Bo Peng wrote: When LyX is run in place, lyx2lyx_version.py should be found in the build_support dir. IIRC, the build_support dir is not correctly spotted in a native Windows build. Run lyx -dbg init to check it. I am not quite sure how autotools handle lyx2lyx_version.py but for scons, it is generated from lyx2lyx_version.py.in during installation. It is placed in the destimation directory while autotools put it in src/lib before copying to dest dir. With autotools it is put in the build dir. For some reason it is not found there anymore, this has worked at some point. That is to say, this file is only available after 'scons install', and will not present in src/lib. It should indeed not be in src/lib, but in the build dir. For regulaar development one should not need to install LyX. Georg
Re: trunk: lyx2lyx problem
On Mon, Sep 04, 2006 at 04:16:28PM +0200, Georg Baum wrote: Bo Peng wrote: When LyX is run in place, lyx2lyx_version.py should be found in the build_support dir. IIRC, the build_support dir is not correctly spotted in a native Windows build. Run lyx -dbg init to check it. I am not quite sure how autotools handle lyx2lyx_version.py but for scons, it is generated from lyx2lyx_version.py.in during installation. It is placed in the destimation directory while autotools put it in src/lib before copying to dest dir. With autotools it is put in the build dir. For some reason it is not found there anymore, this has worked at some point. Seemingly it is still working. At least I don't notice anything weird when running lyx in place. -- Enrico
Re: trunk: lyx2lyx problem
Bo Peng wrote: When using autotools lyx2lyx_version.py is generated in lib/lyx2lyx under the build directory. If you run lyx in place, this directory is also taken into account and thus lyx2lyx_version.py is found: I agree that this is convenient, but it is against the idea of source/build separation. Right now, a scons build will not touch or create any file (including config.h) in the source directory. I am not sure it is a good idea to change it. For scons, I'd say keep it like it is now. CMake needs to so something about that... Abdel.
Re: trunk: lyx2lyx problem
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> IIRC, the build_support dir is not correctly spotted in a Enrico> native Windows build. Run "lyx -dbg init" to check it. It would be nice to investigate this. JMarc
Re: trunk: lyx2lyx problem
On Sun, Sep 03, 2006 at 11:05:53PM -0500, Bo Peng wrote: > > When using autotools lyx2lyx_version.py is generated in lib/lyx2lyx > > under the build directory. If you run lyx in place, this directory > > is also taken into account and thus lyx2lyx_version.py is found: > > I agree that this is convenient, but it is against the idea of > source/build separation. Right now, a scons build will not touch or > create any file (including config.h) in the source directory. I am not > sure it is a good idea to change it. The source directory is not touched at all. A lib/lyx2lyx dir is created in the build directory and lyx2lyx_version.py is put there. This directory is then added to the libdir search path when it is detected that lyx is run in place. -- Enrico
Re: trunk: lyx2lyx problem
On Mon, Sep 04, 2006 at 11:08:31AM +0200, Jean-Marc Lasgouttes wrote:
> > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> Enrico> IIRC, the build_support dir is not correctly spotted in a
> Enrico> native Windows build. Run "lyx -dbg init" to check it.
>
> It would be nice to investigate this.
Look at package.C.in:
std::string const
get_build_support_dir(std::string const & binary_dir,
exe_build_dir_to_top_build_dir top_build_dir_location)
{
string indirection;
switch (top_build_dir_location) {
case top_build_dir_is_one_level_up:
indirection = "../lib";
break;
case top_build_dir_is_two_levels_up:
indirection = "../../lib";
break;
}
return normalizePath(addPath(binary_dir, indirection));
}
This is not going to work when packaging is windows or macosx...
--
Enrico
Re: trunk: lyx2lyx problem
Bo Peng wrote: >> When LyX is run in place, lyx2lyx_version.py should be found in the >> build_support dir. IIRC, the build_support dir is not correctly spotted >> in a native Windows build. Run "lyx -dbg init" to check it. > > I am not quite sure how autotools handle lyx2lyx_version.py but for > scons, it is generated from lyx2lyx_version.py.in during installation. > It is placed in the destimation directory while autotools put it in > src/lib before copying to dest dir. With autotools it is put in the build dir. For some reason it is not found there anymore, this has worked at some point. > That is to say, this file is only > available after 'scons install', and will not present in src/lib. It should indeed not be in src/lib, but in the build dir. For regulaar development one should not need to install LyX. Georg
Re: trunk: lyx2lyx problem
On Mon, Sep 04, 2006 at 04:16:28PM +0200, Georg Baum wrote: > Bo Peng wrote: > > >> When LyX is run in place, lyx2lyx_version.py should be found in the > >> build_support dir. IIRC, the build_support dir is not correctly spotted > >> in a native Windows build. Run "lyx -dbg init" to check it. > > > > I am not quite sure how autotools handle lyx2lyx_version.py but for > > scons, it is generated from lyx2lyx_version.py.in during installation. > > It is placed in the destimation directory while autotools put it in > > src/lib before copying to dest dir. > > With autotools it is put in the build dir. For some reason it is not found > there anymore, this has worked at some point. Seemingly it is still working. At least I don't notice anything weird when running lyx in place. -- Enrico
Re: trunk: lyx2lyx problem
José Matos wrote: On Saturday 02 September 2006 09:07, Abdelrazak Younes wrote: ImportError: No module named lyx2lyx_version This is with a CMake build, so maybe this explains that. Peter, any clue? There is a file lyx2lyx_version.py.in that is converted with both autotools and scons. The resulting file is place in the distdir while all other files are not. That is the problem. So this means that neither scons nor autotools will work exclusively with trunk/lib? I mean without a make install? I see that scons put that in trunk/development/scons/program/lyx-msvc/Resources/lyx2lyx/ and that Ressources directory is used instead of the trunk/lib dir. Abdel.
Re: trunk: lyx2lyx problem
On Sunday 03 September 2006 10:28, Abdelrazak Younes wrote: So this means that neither scons nor autotools will work exclusively with trunk/lib? I mean without a make install? They do, but I had not explored how they do it. :-) -- José Abílio
Re: trunk: lyx2lyx problem
José Matos wrote: On Sunday 03 September 2006 10:28, Abdelrazak Younes wrote: So this means that neither scons nor autotools will work exclusively with trunk/lib? I mean without a make install? They do, but I had not explored how they do it. :-) If I understand correctly Andre and Georg report it seems that they do not... Abdel.
Re: trunk: lyx2lyx problem
If I understand correctly Andre and Georg report it seems that they do not... I run 'scons install' instead of 'scons lyx' or 'scons all' to test lyx. This is safer although you can run scons install once to get the lib files in place, and then 'scons lyx' to build lyx later. Note that scons install only installs changed files. Bo
Re: trunk: lyx2lyx problem
Bo Peng wrote: If I understand correctly Andre and Georg report it seems that they do not... I run 'scons install' instead of 'scons lyx' or 'scons all' to test lyx. This is safer although you can run scons install once to get the lib files in place, and then 'scons lyx' to build lyx later. When developing I run LyX directly from MSVC. Even more so when debugging. Note that scons install only installs changed files. Yep, that's a good feature. Abdel.
Re: trunk: lyx2lyx problem
On Sun, Sep 03, 2006 at 06:49:34PM +0100, José Matos wrote: On Sunday 03 September 2006 10:28, Abdelrazak Younes wrote: So this means that neither scons nor autotools will work exclusively with trunk/lib? I mean without a make install? They do, but I had not explored how they do it. :-) When LyX is run in place, lyx2lyx_version.py should be found in the build_support dir. IIRC, the build_support dir is not correctly spotted in a native Windows build. Run lyx -dbg init to check it. -- Enrico
Re: trunk: lyx2lyx problem
When LyX is run in place, lyx2lyx_version.py should be found in the build_support dir. IIRC, the build_support dir is not correctly spotted in a native Windows build. Run lyx -dbg init to check it. I am not quite sure how autotools handle lyx2lyx_version.py but for scons, it is generated from lyx2lyx_version.py.in during installation. It is placed in the destimation directory while autotools put it in src/lib before copying to dest dir. That is to say, this file is only available after 'scons install', and will not present in src/lib. Bo
Re: trunk: lyx2lyx problem
On Sun, Sep 03, 2006 at 09:25:48PM -0500, Bo Peng wrote: When LyX is run in place, lyx2lyx_version.py should be found in the build_support dir. IIRC, the build_support dir is not correctly spotted in a native Windows build. Run lyx -dbg init to check it. I am not quite sure how autotools handle lyx2lyx_version.py but for scons, it is generated from lyx2lyx_version.py.in during installation. It is placed in the destimation directory while autotools put it in src/lib before copying to dest dir. That is to say, this file is only available after 'scons install', and will not present in src/lib. When using autotools lyx2lyx_version.py is generated in lib/lyx2lyx under the build directory. If you run lyx in place, this directory is also taken into account and thus lyx2lyx_version.py is found: $ ./lyx -dbg init Setting debug level to init Debugging `init' (Program initialisation) Checking whether LyX is run in place... yes package binary_dir /usr/local/src/lyx/lyx-1.5.0svn/build-cygwin/src/ system_support /usr/local/src/lyx/lyx-1.5.0svn/lib/ build_support /usr/local/src/lyx/lyx-1.5.0svn/build-cygwin/lib/ user_support /c/work/.lyx-1.5.0svn/ locale_dir /usr/local/share/locale document_dir /c/work temp_dir /tmp home_dir /c/work /package ... $ cd ~ $ lyx -dbg init Setting debug level to init Debugging `init' (Program initialisation) Checking whether LyX is run in place... no package binary_dir /usr/local/bin/ system_support /usr/local/share/lyx/ build_support user_support /c/work/.lyx/ locale_dir /usr/local/share/locale/ document_dir /c/work temp_dir /tmp home_dir /c/work /package ... -- Enrico
Re: trunk: lyx2lyx problem
When using autotools lyx2lyx_version.py is generated in lib/lyx2lyx under the build directory. If you run lyx in place, this directory is also taken into account and thus lyx2lyx_version.py is found: I agree that this is convenient, but it is against the idea of source/build separation. Right now, a scons build will not touch or create any file (including config.h) in the source directory. I am not sure it is a good idea to change it. Bo
Re: trunk: lyx2lyx problem
José Matos wrote: On Saturday 02 September 2006 09:07, Abdelrazak Younes wrote: ImportError: No module named lyx2lyx_version This is with a CMake build, so maybe this explains that. Peter, any clue? There is a file lyx2lyx_version.py.in that is converted with both autotools and scons. The resulting file is place in the distdir while all other files are not. That is the problem. So this means that neither scons nor autotools will work exclusively with trunk/lib? I mean without a "make install"? I see that scons put that in "trunk/development/scons/program/lyx-msvc/Resources/lyx2lyx/" and that Ressources directory is used instead of the "trunk/lib" dir. Abdel.
Re: trunk: lyx2lyx problem
On Sunday 03 September 2006 10:28, Abdelrazak Younes wrote: > So this means that neither scons nor autotools will work exclusively > with trunk/lib? I mean without a "make install"? They do, but I had not explored how they do it. :-) -- José Abílio
Re: trunk: lyx2lyx problem
José Matos wrote: On Sunday 03 September 2006 10:28, Abdelrazak Younes wrote: So this means that neither scons nor autotools will work exclusively with trunk/lib? I mean without a "make install"? They do, but I had not explored how they do it. :-) If I understand correctly Andre and Georg report it seems that they do not... Abdel.
Re: trunk: lyx2lyx problem
If I understand correctly Andre and Georg report it seems that they do not... I run 'scons install' instead of 'scons lyx' or 'scons all' to test lyx. This is safer although you can run scons install once to get the lib files in place, and then 'scons lyx' to build lyx later. Note that scons install only installs changed files. Bo
Re: trunk: lyx2lyx problem
Bo Peng wrote: If I understand correctly Andre and Georg report it seems that they do not... I run 'scons install' instead of 'scons lyx' or 'scons all' to test lyx. This is safer although you can run scons install once to get the lib files in place, and then 'scons lyx' to build lyx later. When developing I run LyX directly from MSVC. Even more so when debugging. Note that scons install only installs changed files. Yep, that's a good feature. Abdel.
Re: trunk: lyx2lyx problem
On Sun, Sep 03, 2006 at 06:49:34PM +0100, José Matos wrote: > On Sunday 03 September 2006 10:28, Abdelrazak Younes wrote: > > So this means that neither scons nor autotools will work exclusively > > with trunk/lib? I mean without a "make install"? > > They do, but I had not explored how they do it. :-) When LyX is run in place, lyx2lyx_version.py should be found in the build_support dir. IIRC, the build_support dir is not correctly spotted in a native Windows build. Run "lyx -dbg init" to check it. -- Enrico
Re: trunk: lyx2lyx problem
When LyX is run in place, lyx2lyx_version.py should be found in the build_support dir. IIRC, the build_support dir is not correctly spotted in a native Windows build. Run "lyx -dbg init" to check it. I am not quite sure how autotools handle lyx2lyx_version.py but for scons, it is generated from lyx2lyx_version.py.in during installation. It is placed in the destimation directory while autotools put it in src/lib before copying to dest dir. That is to say, this file is only available after 'scons install', and will not present in src/lib. Bo
Re: trunk: lyx2lyx problem
On Sun, Sep 03, 2006 at 09:25:48PM -0500, Bo Peng wrote: > > When LyX is run in place, lyx2lyx_version.py should be found in the > > build_support dir. IIRC, the build_support dir is not correctly spotted > > in a native Windows build. Run "lyx -dbg init" to check it. > > I am not quite sure how autotools handle lyx2lyx_version.py but for > scons, it is generated from lyx2lyx_version.py.in during installation. > It is placed in the destimation directory while autotools put it in > src/lib before copying to dest dir. That is to say, this file is only > available after 'scons install', and will not present in src/lib. When using autotools lyx2lyx_version.py is generated in lib/lyx2lyx under the build directory. If you run lyx in place, this directory is also taken into account and thus lyx2lyx_version.py is found: $ ./lyx -dbg init Setting debug level to init Debugging `init' (Program initialisation) Checking whether LyX is run in place... yes binary_dir /usr/local/src/lyx/lyx-1.5.0svn/build-cygwin/src/ system_support /usr/local/src/lyx/lyx-1.5.0svn/lib/ build_support /usr/local/src/lyx/lyx-1.5.0svn/build-cygwin/lib/ user_support /c/work/.lyx-1.5.0svn/ locale_dir /usr/local/share/locale document_dir /c/work temp_dir /tmp home_dir /c/work ... $ cd ~ $ lyx -dbg init Setting debug level to init Debugging `init' (Program initialisation) Checking whether LyX is run in place... no binary_dir /usr/local/bin/ system_support /usr/local/share/lyx/ build_support user_support /c/work/.lyx/ locale_dir /usr/local/share/locale/ document_dir /c/work temp_dir /tmp home_dir /c/work ... -- Enrico
Re: trunk: lyx2lyx problem
When using autotools lyx2lyx_version.py is generated in lib/lyx2lyx under the build directory. If you run lyx in place, this directory is also taken into account and thus lyx2lyx_version.py is found: I agree that this is convenient, but it is against the idea of source/build separation. Right now, a scons build will not touch or create any file (including config.h) in the source directory. I am not sure it is a good idea to change it. Bo
Re: trunk: lyx2lyx problem
On Saturday 02 September 2006 09:07, Abdelrazak Younes wrote: ImportError: No module named lyx2lyx_version This is with a CMake build, so maybe this explains that. Peter, any clue? There is a file lyx2lyx_version.py.in that is converted with both autotools and scons. The resulting file is place in the distdir while all other files are not. That is the problem. Abdel. -- José Abílio
Re: trunk: lyx2lyx problem
On Saturday 02 September 2006 09:07, Abdelrazak Younes wrote: > ImportError: No module named lyx2lyx_version > > This is with a CMake build, so maybe this explains that. Peter, any clue? There is a file lyx2lyx_version.py.in that is converted with both autotools and scons. The resulting file is place in the distdir while all other files are not. That is the problem. > Abdel. -- José Abílio
