Re: Scons: almost there
"Bo Peng" <[EMAIL PROTECTED]> writes: | > It is not basic building I worry about. It is things like distcheck, | > gettext, pch, warnings, stdlib-debug, install, stage-dir etc. etc. | > that I worry about. | | These will be added on a one by one basis. The advantage of scons is | that (almost) anyone can read SConstruct and add the feature he wants. | I *will not* add every single feature that autotools have now. You see, I am not confident that it can easily be done with scons at all. So to nullify my worries _you_ have to show that it can be done. If none of the scons proponents are willing to do this it is doomed already. | | > I see no or littel support for these in scons, so _you_ have to show | > that it can be done. (and not that that compiler args vary between | > compiler versions, not just between compiler brands) | | No. I have no intention, as of now, to replace autotools with scons. | All I need is a quicker and more flexible method to build lyx for my | own lyx coding. This makes it even more unlikely that scons support will stay in trunk. | I have shown some advantages of scons over autotools | under linux, I have seen none. | Doing all these "scons dist" stuff, as I have said before, is | possible. There are code everywhere (even at the end of | scons_utils.py) but since scons is standardizing these features. It is | much wiser to wait. So should our support for it then -- Lgb
Re: Scons: almost there
On Tue, May 09, 2006 at 12:41:26PM -0500, Bo Peng wrote:
> >--- SConstruct.orig 2006-05-09 16:29:42.0 +0200
> >+++ SConstruct 2006-05-09 19:24:12.0 +0200
> >@@ -706,7 +706,7 @@
> > if ARGUMENTS.get('mode', default_build_mode) == 'debug':
> > env.Append(CCFLAGS = [])
> > else:
> >- env.Append(CCFLAGS = [])
> >+ env.Append(CCFLAGS = ['-O2'])
>
> Is this '-' universal? I mean, will other compiler (or gcc under
> other platforms) use it, instead of things like "icc /O2'?
No, clearly. There should be a way to pass at least CC, CPP, CFLAGS,
CXX, CXXCPP, CXXFLAGS, and LDFLAGS, maybe through the environment.
--
Enrico
Re: Scons: almost there
--- SConstruct.orig 2006-05-09 16:29:42.0 +0200
+++ SConstruct 2006-05-09 19:24:12.0 +0200
@@ -706,7 +706,7 @@
if ARGUMENTS.get('mode', default_build_mode) == 'debug':
env.Append(CCFLAGS = [])
else:
- env.Append(CCFLAGS = [])
+ env.Append(CCFLAGS = ['-O2'])
Is this '-' universal? I mean, will other compiler (or gcc under
other platforms) use it, instead of things like "icc /O2'?
Bo
Re: Scons: almost there
On Tue, May 09, 2006 at 11:11:39AM -0500, Bo Peng wrote:
> Before I figure out how to pass -O3, you can edit line 707 of
> Sconstruct and add things like ['O3']. (Not tested)
This one did the trick:
--- SConstruct.orig 2006-05-09 16:29:42.0 +0200
+++ SConstruct 2006-05-09 19:24:12.0 +0200
@@ -706,7 +706,7 @@
if ARGUMENTS.get('mode', default_build_mode) == 'debug':
env.Append(CCFLAGS = [])
else:
- env.Append(CCFLAGS = [])
+ env.Append(CCFLAGS = ['-O2'])
#
# Customized builders
--
Enrico
Re: Scons: almost there
BTW what's the problem with aspell? I mean, it seems that "spell=aspell" fails in the final link step (even adding by hand -laspell). I added that option, and I have spell libraries checked, but did not add the libraries in. (search spell in SConstructt) Bo
Re: Scons: almost there
On Tue, May 09, 2006 at 11:11:39AM -0500, Bo Peng wrote: > >Using scons it takes only 2/3 of the time needed using auto* stuff > >for me on cygwin. But it seems that I cannot convince scons to compile > >using -O2 so, I am sorry, but the comparison is unfair. > > So you mean you succeed? Great to know. Almost. It seems I can't have aspell support. > Before I figure out how to pass -O3, you can edit line 707 of > Sconstruct and add things like ['O3']. (Not tested) I think I am fine with '-O2' ;-) BTW what's the problem with aspell? I mean, it seems that "spell=aspell" fails in the final link step (even adding by hand -laspell). -- Enrico
Re: Scons: almost there
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes: Bo> Waf also claims to cache initial thinking process so null build Bo> (Lars reported a number around 24s) should be shorter there. Especially since null build are known to be very bad with recursive makefiles like we are using here. So a good build system should be able to be really faster than an automake-based one. BTW, with ccache, I can do 'make clean; make' in something like 13 minutes (on 1.4)... JMarc
Re: Scons: almost there
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes: Bo> I know. scons lacks of a huge library of such things. I actually Bo> copied the SELECT_ARG thing from the autoconf source code. OK. So the big problem would be to make gettext fit in? >> Is there hope to avoid requiring installing SCons before compiling >> LyX from tar.gz? The python requirement itself is pretty much OK, >> since we use it elsewhere. Bo> Such a thing exists. It is called scons-local, readily Bo> downloadable with scons source. If some procedure requires Bo> ./configure. make, make install, we can fake them. I see it uses 200k when zipped, which is comparable to a configure script. So it is not too bad, but the global footprint will remain the same. JMarc
Re: Scons: almost there
Using scons it takes only 2/3 of the time needed using auto* stuff for me on cygwin. But it seems that I cannot convince scons to compile using -O2 so, I am sorry, but the comparison is unfair. So you mean you succeed? Great to know. Before I figure out how to pass -O3, you can edit line 707 of Sconstruct and add things like ['O3']. (Not tested) Bo
Re: Scons: almost there
On Tue, May 09, 2006 at 10:09:11AM -0500, Bo Peng wrote: > >I have an idea for you Bo. Instead of specifying > >"extra_inc_path=d:/mingw/include extra_lib_path=d:/mingw/lib" it would > >be better to specify "with_mingw=d:/mingw". Then Scons could add > >automatically the include and lib paths. _And_ Scons could search the > >required dll in "d:/mingw/bin/". > > Agreed. Can I leave this to you as a Python exercise? It is time for > you to read the Python tutorial (You do not even need that for this > change.) > > BTW, have you tried the updated system? If possible, you can record > the compiling time and post to the comparison thread. Using scons it takes only 2/3 of the time needed using auto* stuff for me on cygwin. But it seems that I cannot convince scons to compile using -O2 so, I am sorry, but the comparison is unfair. -- Enrico
Re: Scons: almost there
And yes, I have > 130 days of paid leave :) If finding a job in French is easy, I will try to go there. Bo> These will be added on a one by one basis. The advantage of scons Bo> is that (almost) anyone can read SConstruct and add the feature he Bo> wants. I *will not* add every single feature that autotools have Bo> now. But you will eventually? I do not know. If something comes out as a request, I (or someone else) will add it. If it does not show up till the end, that means this feature is not needed. The idea of reimplementing the m4 code I wrote in python because you prefer python to autoconf does not appeal to me a lot. I know. scons lacks of a huge library of such things. I actually copied the SELECT_ARG thing from the autoconf source code. However, if something is not readily available, it will be much easier for me to implement in Python. I guess you can read scons_utils.py and make your judgement. (BTW, we do need to copy various autoconf macros to the config directory, and those macros are usually longer (and more obscure) than their python counterparts.) Bo> No. I have no intention, as of now, to replace autotools with Bo> scons. All I need is a quicker and more flexible method to build Bo> lyx for my own lyx coding. I have shown some advantages of scons Bo> over autotools under linux, and Abdel will surely show you more Bo> gains under windows. That is currently enough for us. Is there hope to avoid requiring installing SCons before compiling LyX from tar.gz? The python requirement itself is pretty much OK, since we use it elsewhere. Such a thing exists. It is called scons-local, readily downloadable with scons source. If some procedure requires ./configure. make, make install, we can fake them. Bo
Re: Scons: almost there
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes: >> And you clearly showed that you had no patience. Bo> I heard that French people have >130 days of paid leave? Lars is not french, you know. And some french people have families and choose to spend their week-ends with them. And yes, I have > 130 days of paid leave :) >> It is not basic building I worry about. It is things like >> distcheck, gettext, pch, warnings, stdlib-debug, install, stage-dir >> etc. etc. that I worry about. Bo> These will be added on a one by one basis. The advantage of scons Bo> is that (almost) anyone can read SConstruct and add the feature he Bo> wants. I *will not* add every single feature that autotools have Bo> now. But you will eventually? The idea of reimplementing the m4 code I wrote in python because you prefer python to autoconf does not appeal to me a lot. Bo> No. I have no intention, as of now, to replace autotools with Bo> scons. All I need is a quicker and more flexible method to build Bo> lyx for my own lyx coding. I have shown some advantages of scons Bo> over autotools under linux, and Abdel will surely show you more Bo> gains under windows. That is currently enough for us. Is there hope to avoid requiring installing SCons before compiling LyX from tar.gz? The python requirement itself is pretty much OK, since we use it elsewhere. JMarc
Re: Scons: almost there
I have an idea for you Bo. Instead of specifying "extra_inc_path=d:/mingw/include extra_lib_path=d:/mingw/lib" it would be better to specify "with_mingw=d:/mingw". Then Scons could add automatically the include and lib paths. _And_ Scons could search the required dll in "d:/mingw/bin/". Agreed. Can I leave this to you as a Python exercise? It is time for you to read the Python tutorial (You do not even need that for this change.) BTW, have you tried the updated system? If possible, you can record the compiling time and post to the comparison thread. Bo
Re: Scons: almost there
Bo Peng a écrit : I just submitted another patch. With it, one can 0. scons directly under linux + lyx qt3/qt4 ... (state of yesterday) 1. scons directly using mingw + lyx qt3/4 + official zlib1.dll in a visible place I have an idea for you Bo. Instead of specifying "extra_inc_path=d:/mingw/include extra_lib_path=d:/mingw/lib" it would be better to specify "with_mingw=d:/mingw". Then Scons could add automatically the include and lib paths. _And_ Scons could search the required dll in "d:/mingw/bin/". Abdel.
Re: Scons: almost there
And you clearly showed that you had no patience. I heard that French people have >130 days of paid leave? It is not basic building I worry about. It is things like distcheck, gettext, pch, warnings, stdlib-debug, install, stage-dir etc. etc. that I worry about. These will be added on a one by one basis. The advantage of scons is that (almost) anyone can read SConstruct and add the feature he wants. I *will not* add every single feature that autotools have now. I see no or littel support for these in scons, so _you_ have to show that it can be done. (and not that that compiler args vary between compiler versions, not just between compiler brands) No. I have no intention, as of now, to replace autotools with scons. All I need is a quicker and more flexible method to build lyx for my own lyx coding. I have shown some advantages of scons over autotools under linux, and Abdel will surely show you more gains under windows. That is currently enough for us. Totally usable is not good enough. It must handle the same problems as autotools does. I am not saying that this must be done promtly, but at least it must be shown that it can be done. (and without creating something that is just as complex as auto*) Doing all these "scons dist" stuff, as I have said before, is possible. There are code everywhere (even at the end of scons_utils.py) but since scons is standardizing these features. It is much wiser to wait. | BTW, much of my time has been wasted on the .C/.c madness under | windows. You mean "The Windows madness"... You may rightly say so. Bo
Re: Scons: almost there
Is the problem fixed or not? yes, But as pointed out, scons is not the only reason for renaming, (and I choose to propse a rename *after* scons fixes the problem.) Please no renaming in 1.4.x. Your decision is mine. Bo
Re: Scons: almost there
"Bo Peng" <[EMAIL PROTECTED]> writes: | | We are getting closer, I think. I still have to find time to make up | my mind about non/auto/"". | | Patience ;) | And you clearly showed that you had no patience. | I just submitted another patch. With it, one can | 0. scons directly under linux + lyx qt3/qt4 ... (state of yesterday) | 1. scons directly using mingw + lyx qt3/4 + official zlib1.dll in a | visible place | 2. scons in a native cygwin, cygwin/qt3, cygwin/boost, cygwin/zlib etc. It is not basic building I worry about. It is things like distcheck, gettext, pch, warnings, stdlib-debug, install, stage-dir etc. etc. that I worry about. I see no or littel support for these in scons, so _you_ have to show that it can be done. (and not that that compiler args vary between compiler versions, not just between compiler brands) | With some tweak regarding spell checkers and a few other libraries | (maybe also pch), and some scons install capacity, this will be a | totally usable. I hope this will earn scons a place in the trunk. Totally usable is not good enough. It must handle the same problems as autotools does. I am not saying that this must be done promtly, but at least it must be shown that it can be done. (and without creating something that is just as complex as auto*) | BTW, much of my time has been wasted on the .C/.c madness under | windows. You mean "The Windows madness"... -- Lgb
Re: Scons: almost there
I forgot to thank Abdel, who figured out the right libraries to link under mingw. His work on identifying *used* macros in config.h also helped a lot. Thanks again. Bo
Re: Scons: almost there
Bo Peng wrote: > BTW, much of my time has been wasted on the .C/.c madness under > windows. Although scons has overcomed this problem, can we make a > quick decision regarding the name change? After all, it is only "find > ... svn rename grep .. Makefile.am... perl -pi.bak" away. If you > are worrying about backporting, let us do it on 1.4.x as well. I thought that initially, too, but there is a good reason for not doing it: Providing a patch from 1.4.1 to 1.4.2 would not make sense anymore. Georg
Re: Scons: almost there
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes: Bo> Dear all, >> If nothing happens with scons in the next couple of days, I am >> going to remove it from trunk. Bo> Since when have you become so time-conscious? May I ask again Bo> ? Bo> We are getting closer, I think. I still have Bo> to find time to make up my mind about non/auto/"". Bo> Patience ;) First quote was Lars. Second one is me. Bo> BTW, much of my time has been wasted on the .C/.c madness under Bo> windows. Although scons has overcomed this problem, can we make a Bo> quick decision regarding the name change? After all, it is only Bo> "find ... svn rename grep .. Makefile.am... perl -pi.bak" Bo> away. Is the problem fixed or not? Bo> If you are worrying about backporting, let us do it on 1.4.x as Bo> well. Please no renaming in 1.4.x. JMarc
