Re: [IPCop-devel] rolling back changes to make.sh and then reapplyingthem one at a time

[Gilles E. <g....@fr...>]

----- Original Message -----=20
From: "Franck Bourdonnec" <fbo...@ch...>
To: <ipc...@li...>
Sent: Sunday, July 30, 2006 1:02 PM
Subject: Re: [IPCop-devel] rolling back changes to make.sh and then
reapplyingthem one at a time


> Le dimanche 30 juillet 2006 11:02, Ivan Kabaivanov a =E9crit :
> > Does anyone object to my rolling back everything since 1.253 and then
> > putting it back in smaller increments, grouped by affected
functionality?
> > I plan to retain pretty much all of the changes.  However I'll fix so=
me
> > small things, build upon Franck's good ideas about the new configure =
and
> > address Gilles' concerns with the scriptability of the build process.
Oh,
> > and fix spaces vs tabs :-)  Remember, we settled on tabs.
>
>sorry for tabs I never think to them.
>
>Gilles sriptability is REALLY A FALSE PROBLEM.
>Before:
>  his script was generating on the fly response (echo "yes">>
>now  it to generate on the fly .config and problem is gone.
>
>More, his nightly while I'm sleeping script, while not be dependant
>on make.sh asking question.
>
>.config : it is not important to spend a lot of time on it. Gilles wante=
d
>the choice to show what was in a previous config (reconfig!). In
>make.sh, it is very basic. If someone wants to write an xconfig
>or menuconfig like  kernel, he can. Important is to provide one.
>

I don't want to see regression like be forced to answer ununderstandable
questions every time I have run ./make.sh clean. This is why I commented =
out
erasing the .config file every time.
Yes we have to think that make.sh could be called by a script.
Maybe passing a .config file name to make.sh and have a .config-glibc and=
 a
.config-uclibc?
>
> I won't commit anything before I get a consensus and not before I've
> prepared the incremental patches so as to minimize the "downtime."
>
> And one more question since we're on the topic of make.sh.  I've been
> toying with the idea of allowing multiple build directories in the same
> tree.  Right now we can have only one glibc and one uclibc directory.  =
 My
> idea is to use mktemp to create directories like this:
...
>> Having multiple directories could be usefull if you want to build in
>> parallel, experiment with something in one session, add new package in
>> another, etc.
>>
>> I'm just not sure if this is something useful and the time spent on
>> implementing it a time wasted.
>>
>> How do you guys feel?
>> IvanK.
>
>until it is not done, nobody find it usefull ! I'm not sure what I
>could do with this because I solve it
>-with two machines
>-or ask a new cvs snapshot (thus the cache link!!!)
>
I don't think I need that.
Building in a new tree is space and time consuming.
Night time is just to build 1.4, 15 glibc and uclibc on a Barton 2800 if =
I
did not start the build to late in the night.
I am afraid parallel build would need a powerfull cluster and even with
distcc, this is difficult to set to work on some parts of the toolchain.
I understand gcc-4.1.1 may have desired features and that we could take t=
he
time until hardened build is ready.
I would prefer if we could start soon to concentrate on the features we w=
ill
make available on v1.5.
There is many packages wich need upgrade and accurate tuning to work on
v1.5.
We have too to make choices which features will be include on v1.5 and wh=
ich
will be delivered later. This way, we could think a day to finalize v1.5
...

> A better thing would be a second 'prebuilt' env with base ipcop.
> So that any body can start rapidly concentrate on an addon working or G=
UI
etc etc etc...
Yes considering time to build. But this will need space and is not yet
technically ready.
The last time I try using the i486 toolchain package (build on a i686) to
build the remaining on a i586, this had failed. With a i486 toolchain
rebuild on the same i586, this was very long but was succesfull.

> Another extension I plan (you can think I too):
> many developper have addons with compiled
> tools 'somewhere'. I want to add another lfs
> dir with extra script. They won't be compiled
> in delivered official IPCop. They won't be
> distributed by us. Only ready to be compiled
> accordingly to our security (gcc) model.
> After that the developper addon package
> it's job as he want.
> This is another step in addon integration.

I think adding a add-on target directory, a few explanations how to use
that, could be enought

>conclusion:
>
> don't understand why revert to 253 to reapply things...
It is just because the way you do it, it is very uneasy to understand wha=
t
changes was really made and on what purpose.

Gilles