Just tested. It is broken. Saving/restoring env is more difficult
than I expected. :-( Actually, with all the cached tests, I do not
save much time either.
Fast_start is back. I was trying to find a real fix other than an
unnecessary io.h test, and forget to restore the test afterwards.
BOOST
On 20 Jun 2006 18:20:16 +0200, Lars Gullik Bjønnes <[EMAIL PROTECTED]> wrote:
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > That is what we have setup automake to do.
| > (except that we have so far not bothered to split config.h)
|
| Really? src/config.h.in:
Hmm da hmm... you are right...
We shou
On Tuesday 20 June 2006 17:20, Lars Gullik Bjønnes wrote:
> "Bo Peng" <[EMAIL PROTECTED]> writes:
> | > That is what we have setup automake to do.
> | > (except that we have so far not bothered to split config.h)
> |
> | Really? src/config.h.in:
>
> Hmm da hmm... you are right...
>
> We should prob
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > That is what we have setup automake to do.
| > (except that we have so far not bothered to split config.h)
|
| Really? src/config.h.in:
Hmm da hmm... you are right...
We should probably create boost_config.h for autotools as well. That
would avoid the i
That is what we have setup automake to do.
(except that we have so far not bothered to split config.h)
Really? src/config.h.in:
#define BOOST_USER_CONFIG
#if !defined(ENABLE_ASSERTIONS)
# define BOOST_DISABLE_ASSERTS 1
#endif
#define BOOST_ENABLE_ASSERT_HANDLER 1
You see, I am trying to be
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Right, when compiling boost .cpp file you have to pass
| DBOOST_USER_CONFIG= to the compiler. That's
| what scons do already, isn't it?
That is what we have setup automake to do.
(except that we have so far not bothered to split config.h)
--
Bo Peng wrote:
I think it is the other way around Bo. BOOST_USER_CONFIG is defined in
"common/config.h" for all lyx files. If a lyx file include some boost
header, the boost_header will look automatically into the file defined
by BOOST_USER_CONFIG. So no need to redefine this macro inside
boost/c
I think it is the other way around Bo. BOOST_USER_CONFIG is defined in
"common/config.h" for all lyx files. If a lyx file include some boost
header, the boost_header will look automatically into the file defined
by BOOST_USER_CONFIG. So no need to redefine this macro inside
boost/config.h.
lyx s
Bo Peng wrote:
But do we need "#define BOOST_USER_CONFIG " in there also?
It should be in boost/config.h, and passed to boost source files. You
can check scons_lyx.log. I do not think this is need for lyx osurces,
but I might be wrong.
I think it is the other way around Bo. BOOST_USER_CONFIG
But do we need "#define BOOST_USER_CONFIG " in there also?
It should be in boost/config.h, and passed to boost source files. You
can check scons_lyx.log. I do not think this is need for lyx osurces,
but I might be wrong.
Bo
Bo Peng wrote:
> I did not test this
> patch against msvc, but the previous version did work (the
> boost_config.h one).
I think it is a msvc problem indeed because I don't remember having it
with mingw.
This is indeed only with msvc. I guess you know the reason but I can
explain again:
With
>> Also, when I run scons again after the configuration was done, it insist
>> on recompiling everything from the beginning. Running "scons
>> fast_start=no" work as expected. Looks like your patch broke the
>> fast_start=yes option.
Just tested. It is broken. Saving/restoring env is more diff
> I did not test this
> patch against msvc, but the previous version did work (the
> boost_config.h one).
I think it is a msvc problem indeed because I don't remember having it
with mingw.
This is indeed only with msvc. I guess you know the reason but I can
explain again:
With msvc, boost empl
Bo Peng wrote:
It solved the intl include problem but not the boost library problem:
LINK : fatal error LNK1104: cannot open file
'libboost_signals-vc80-mt-s-1_33_1.lib'
Did not you report success with a previous patch?
I don't think so.
I did not test this
patch against msvc, but the pre
It solved the intl include problem but not the boost library problem:
LINK : fatal error LNK1104: cannot open file
'libboost_signals-vc80-mt-s-1_33_1.lib'
Did not you report success with a previous patch? I did not test this
patch against msvc, but the previous version did work (the
boost_confi
Bo Peng wrote:
Abdel, please check if the attached patch has addressed all your concerns.
It solved the intl include problem but not the boost library problem:
LINK : fatal error LNK1104: cannot open file
'libboost_signals-vc80-mt-s-1_33_1.lib'
Also, when I run scons again after the configu
Bo Peng wrote:
Abdel, please check if the attached patch has addressed all your concerns.
Not now, sorry I have to hurry up. Tunisia is playing tonight.
Abdel.
Abdel, please check if the attached patch has addressed all your concerns.
Bo
Index: development/scons/SConstruct
===
--- development/scons/SConstruct (revision 14150)
+++ development/scons/SConstruct (working copy)
@@ -254,7 +254,7
Bo Peng wrote:
If I add /ID:\devel\lyx\GUI\src to it, it compiles fine.
Why intl needs to include $TOP_SRCDIR/src?
This was with the version in trunk, that is before your config.h
separation. I guess that with your patch you need to add
$TOP_SRCDIR/intl to the include path.
Abdel.
If I add /ID:\devel\lyx\GUI\src to it, it compiles fine.
Why intl needs to include $TOP_SRCDIR/src?
Bo
Please find attached a patch for restore the old behaviour for gcc/debug
(by default we don't have debug libraries with mingw).
I will change the patch.
I have a problem with MSVC/debug. The binary complains about missing
MSVCP80D.dll. I think you have to link with QtCored4.dll.manifest and
Qt
Abdelrazak Younes wrote:
Bo Peng wrote:
intl should have its own config.h. Do you see that generated
(intl/config.h)
Yes it is in trunk/intl/config.h which is bad (see my other mail). The
problem lies in the include options I think.
Yes that's an include path problem. With the unpatched
I think that instead of config/ subdir, you should put
- boost_config.h in scons/build_dir/boost
- intl config.h in scons/build_dir/intl (instead of the source dir)
- lyx config.h in scons/build_dir/common
Sounds reasonable. I will do it.
Bo
Bo Peng wrote:
Abdel,
Attached patch adds
$BUILDDIR/config/config.h
$BUILDDIR/config/boost_config.h
with the following behaviors:
1. boost only uses boost_config.h
2. config.h includes boost_config.h
3. different builds have different config.h (nls etc may change from
build to build).
Tested
Bo Peng wrote:
intl should have its own config.h. Do you see that generated
(intl/config.h)
Yes it is in trunk/intl/config.h which is bad (see my other mail). The
problem lies in the include options I think.
One scenario this fails is that the first run does not have
gettext=included, s
Abdelrazak Younes wrote:
I have fixed with brute force the manifest problem. Feel free to find a
better solution.
Patch attached.
Sorry, this patch was against my branch. Please find attached the patch
against trunk.
Abdel.
Index: SConstruct
===
On 6/19/06, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Abdelrazak Younes wrote:
> Bo Peng wrote:
>> Abdel,
>>
>> Attached patch adds
>>
>> $BUILDDIR/config/config.h
>> $BUILDDIR/config/boost_config.h
>>
>> with the following behaviors:
>> 1. boost only uses boost_config.h
>> 2. config.h include
Abdelrazak Younes wrote:
Bo Peng wrote:
Abdel,
Attached patch adds
$BUILDDIR/config/config.h
$BUILDDIR/config/boost_config.h
with the following behaviors:
1. boost only uses boost_config.h
2. config.h includes boost_config.h
3. different builds have different config.h (nls etc may change from
Bo Peng wrote:
Abdel,
Attached patch adds
$BUILDDIR/config/config.h
$BUILDDIR/config/boost_config.h
with the following behaviors:
1. boost only uses boost_config.h
2. config.h includes boost_config.h
3. different builds have different config.h (nls etc may change from
build to build).
Tested
Am Montag, 19. Juni 2006 12:02 schrieb Peter Kümmel:
> Am Montag, 19. Juni 2006 11:50 schrieb Abdelrazak Younes:
> > Jean-Marc Lasgouttes wrote:
> > >> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> > >
> > > Abdelrazak> That looks all very nice Bo :-). I was very frustrated to
Am Montag, 19. Juni 2006 11:50 schrieb Abdelrazak Younes:
> Jean-Marc Lasgouttes wrote:
> >> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> >
> > Abdelrazak> That looks all very nice Bo :-). I was very frustrated to
> > Abdelrazak> have to recompile everything when I switched c
Georg Baum wrote:
Abdelrazak Younes wrote:
Of course that's what I have (actually I have 4 build trees). The
problem was that "config.h" was placed in the source tree. So does
autotools IIRC.
No, it goes to the build tree with autotools, and scons should do the same.
I may have to check tha
Abdelrazak Younes wrote:
> Of course that's what I have (actually I have 4 build trees). The
> problem was that "config.h" was placed in the source tree. So does
> autotools IIRC.
No, it goes to the build tree with autotools, and scons should do the same.
Georg
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> That looks all very nice Bo :-). I was very frustrated to
Abdelrazak> have to recompile everything when I switched compilers.
Abdelrazak> I'll try to test it sometime today.
It seems much safe
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> That looks all very nice Bo :-). I was very frustrated to
Abdelrazak> have to recompile everything when I switched compilers.
Abdelrazak> I'll try to test it sometime today.
It seems much safer to have two build trees
Bo Peng wrote:
Abdel,
Attached patch adds
$BUILDDIR/config/config.h
$BUILDDIR/config/boost_config.h
with the following behaviors:
1. boost only uses boost_config.h
2. config.h includes boost_config.h
3. different builds have different config.h (nls etc may change from
build to build).
Tested
Abdel,
Attached patch adds
$BUILDDIR/config/config.h
$BUILDDIR/config/boost_config.h
with the following behaviors:
1. boost only uses boost_config.h
2. config.h includes boost_config.h
3. different builds have different config.h (nls etc may change from
build to build).
Tested under linux. Ple
Bo Peng wrote:
Ah... So please consider making this in src/boost_config.h instead. This
config file should also be used for external boost.
Then, what is the point of separating the config.h?
For one, if you use the DBOOST_USER_CONFIG="libs/config.h" option then
only the file using boost wil
Ah... So please consider making this in src/boost_config.h instead. This
config file should also be used for external boost.
Then, what is the point of separating the config.h?
Bo
Bo Peng wrote:
> We need to make
> sre libs/config.h exists though.
?? I don't understand... boost/libs/config.h is the file scons is
generating for boost.
Currently, it is generated only when boost=included.
Ah... So please consider making this in src/boost_config.h instead. This
config f
> We need to make
> sre libs/config.h exists though.
?? I don't understand... boost/libs/config.h is the file scons is
generating for boost.
Currently, it is generated only when boost=included.
Bo
Bo Peng wrote:
The version you committed seems to work fine for msvc2005. I gave you
already what I think should go into boost/libs/config.h but let me
repeat that:
Do we need #include "libs/config.h" in src/config.h?
either include it or pass DBOOST_USER_CONFIG="libs/config.h", AFAIU this
i
The version you committed seems to work fine for msvc2005. I gave you
already what I think should go into boost/libs/config.h but let me
repeat that:
Do we need #include "libs/config.h" in src/config.h? We need to make
sre libs/config.h exists though.
Bo
Bo Peng wrote:
Dear all,
Major reorganization of scons has been done for scons. Basically, I
pack everything into SConstruct which results in cleaner and shorter
code (previously, we rely on env to pass messages so there are both
dest_dir and env['DEST_DIR'] etc).
The only user visible change i
44 matches
Mail list logo
