Yes, I use "mode=debug build_dir=msvc-debug" and it works fine.
Good. One less thing to test.
> Yes. There are two ways to specify a path option. The usual option
> allows an non-exist path, and I will have to check and create the path
> myself; and a path option that will accept only pre-exi
Bo Peng wrote:
version_suffix=yes/no/something. Please let me know if it works for you.
It works fine as it created the "lyx1.5.0svn" directory.
Abdel.
Bo Peng wrote:
Right, and as "release" and "debug" are reserved for mingw I created
"msvc" and "msvc-debug". I don't think I had the problem with the
default directory. But I cannot reproduce the problem anymore even after
I deleted the directory, ".sconsign.dblite" and "env.cache".
I will try
But not on windows I hope, is it?
No. On windows, only user directory will change.
Bo
Right, and as "release" and "debug" are reserved for mingw I created
"msvc" and "msvc-debug". I don't think I had the problem with the
default directory. But I cannot reproduce the problem anymore even after
I deleted the directory, ".sconsign.dblite" and "env.cache".
I will try a separate build
Angus Leeming wrote:
Bo Peng writes:
Abdelrazak Younes writes:
I'll try that thanks. And I'll commit the attached patch.
Sure. Note that yes will add package version like 1.4.2svn.
Note also that on *nix, version_suffix will be added to executables, to the
system LyX directory and also to .p
Bo Peng writes:
> Abdelrazak Younes writes:
>> I'll try that thanks. And I'll commit the attached patch.
> Sure. Note that yes will add package version like 1.4.2svn.
Note also that on *nix, version_suffix will be added to executables, to the
system LyX directory and also to .po files.
So your co
Bo Peng wrote:
>> 1) The first time you run scons on a freshly created build
directory it
>> always stop complaining it doesn't have the right to access
"version.C".
>> Then a second call to scons solves the problem.
>
> I will see.
Thanks.
I could not reproduce this bug under linux. If I re
>> 1) The first time you run scons on a freshly created build directory it
>> always stop complaining it doesn't have the right to access "version.C".
>> Then a second call to scons solves the problem.
>
> I will see.
Thanks.
I could not reproduce this bug under linux. If I remove debug
directo
Bo Peng wrote:
I have two bug report for you:
1) The first time you run scons on a freshly created build directory it
always stop complaining it doesn't have the right to access "version.C".
Then a second call to scons solves the problem.
I will see.
Thanks.
2) When compiling with autot
I have two bug report for you:
1) The first time you run scons on a freshly created build directory it
always stop complaining it doesn't have the right to access "version.C".
Then a second call to scons solves the problem.
I will see.
2) When compiling with autotools, I used to pass
"--with
Bo Peng wrote:
Even on a Friday I think that I will start to think about changing
to scons,
after all I get stunned everytime I see configure searching for
fortran and
fortran 95 when testing for lyx requirements.
Good move. I need more testers for scons.
Currently, scons is trying to ensu
Even on a Friday I think that I will start to think about changing to scons,
after all I get stunned everytime I see configure searching for fortran and
fortran 95 when testing for lyx requirements.
Good move. I need more testers for scons.
Currently, scons is trying to ensure a correct build
> "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes:
Jose'> On Friday 07 July 2006 10:12, Jean-Marc Lasgouttes wrote:
>> Why not just apply the following patch?
Jose'> Please do. It should not hurt.
I'll wait for Lars comments. Also our LYX_PROG_LIBTOOL is probably not
needed anymore.
>>
On Friday 07 July 2006 10:12, Jean-Marc Lasgouttes wrote:
> Why not just apply the following patch?
Please do. It should not hurt.
> See the gentoo guy comment:
> http://comments.gmane.org/gmane.comp.sysutils.autoconf.general/6848
>
> Libtool 2.0 is supposed to fix that.
Ah, the old mantra "
> "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes:
Jose'> Even on a Friday I think that I will start to think about
Jose'> changing to scons, after all I get stunned everytime I see
Jose'> configure searching for fortran and fortran 95 when testing for
Jose'> lyx requirements.
Why not jus
On Friday 07 July 2006 04:27, Bo Peng wrote:
> Lars, you might want to fix autotools for this as well. I just tried
> lyx.1.4.2svn with system boost 1.33.1. When I use
> --without-included-boost, configure did not complain with (wrong boost
> version) or without (no boost header)
> --with-extra-inc
I think it means "static". The naming scheme should be pretty standard
as it is produced using --layout=versioned when building boost.
Yes. It is static, I also figured it out from the boost website. With
a patch I just submitted, mt-s is treated as release libraries, and is
also used in debug m
On Thu, Jul 06, 2006 at 10:28:22PM +0200, Enrico Forestieri wrote:
> On Thu, Jul 06, 2006 at 02:47:27PM -0500, Bo Peng wrote:
> > Hi, Enrico,
> >
> > Do you know what this -s suffix mean for cygwin boost libraries? In
> > scons/scons_utils.py, I check for mt-d for debug libraries, mt for
> > rele
On Thu, Jul 06, 2006 at 02:47:27PM -0500, Bo Peng wrote:
> Hi, Enrico,
>
> Do you know what this -s suffix mean for cygwin boost libraries? In
> scons/scons_utils.py, I check for mt-d for debug libraries, mt for
> release libraries, and this fails for cygwin.
>
> /usr/lib/libboost_regex-gcc-mt-s-
Hi, Enrico,
Do you know what this -s suffix mean for cygwin boost libraries? In
scons/scons_utils.py, I check for mt-d for debug libraries, mt for
release libraries, and this fails for cygwin.
/usr/lib/libboost_regex-gcc-mt-s-1_33_1.a
Also, can anyone report name convention for boost/win, boost
21 matches
Mail list logo
