[Buildroot] Properly setting up hotplug

[Buildroot] Properly setting up hotplug

[Sagaert Johan]

Hi 
 
cleaning :
 
I don't trust the disclean, it most ends op in a mess.
 
If i do a clean i do :
 
remove the entire root dir in project_build_arm
remove .root  as well
remove all contents from build_arm
remove all stuff in project_build_arm/../autotools-stamps.
 
i am still wondering why they have put dependencies in
project_build_arm/../autotools-stamps. instead of in build_arm
 
removing the entire root seems the only way to make sure packages enabled in
a previous build and disabled now are no longer a lonely ghost in the
rootfs.
 
 
besides this, there are still othter issues, the libssp.so.0 gets build but
not installed in the target root directory.
 
 
 
Johan
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20090417/77507a20/attachment.htm>

[Buildroot] Properly setting up hotplug

[Thiago A. Corrêa]

Hi,

On Fri, Apr 17, 2009 at 5:33 AM, Sagaert Johan <sagaert.johan@skynet.be> wrote:
> Hi
>
> cleaning :
>
> I don't trust the disclean, it most ends op in a mess.

Same here.

> If i do a clean i do :
>
> remove the entire root dir in project_build_arm
> remove .root? as well
> remove all contents from build_arm
> remove all stuff?in project_build_arm/../autotools-stamps.

I actually will do rm -rf build_* binaries project_* most of the time.
If I'm only fixing a package, I might just remove it's folder in the
build_*, but when I want to make sure everything is proper or when
creating an image to download to the device, I will even remove
toolchain_*

I don't like distclean because it will remove the downloaded files,
and clean usually leaves a lot of stuff in the rootfs.

Kind Regards,
   Thiago A. Correa

[Buildroot] Properly setting up hotplug

[Peter Korsgaard]

>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:

Hi,

 Thiago> I actually will do rm -rf build_* binaries project_* most of
 Thiago> the time.

I normally do rm -rf *build_*.

 Thiago> I don't like distclean because it will remove the downloaded files,

Only if you have it set as BASE_DIR/dl. I expect most people who use
BR on a regular schedule to store their downloads somewhere else.

 Thiago> and clean usually leaves a lot of stuff in the rootfs.

That would be a bug, but yes.

-- 
Bye, Peter Korsgaard

[Buildroot] Properly setting up hotplug

[Lloyd Sargent]

On Apr 17, 2009, at 8:56 AM, Peter Korsgaard wrote:

>>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:
>
> Hi,
>
> Thiago> I don't like distclean because it will remove the downloaded  
> files,
>
> Only if you have it set as BASE_DIR/dl. I expect most people who use
> BR on a regular schedule to store their downloads somewhere else.

I would argue then that, conceptually, for BR there should be two  
forms of distclean:

1) to clean up the projects files (i.e. as if you did 'make distclean'  
for directfb)

2) to clean up ALL of BR (i.e. clean up BR for shipment)

The reasoning is that distclean for a package is DIFFERENT than  
distclean for BR - for obvious reasons.

I understand the desire to keep the same underpinnings (since we all  
know about clean and distclean for particular packages) but because BR  
is not about ONE package but many, I think it is conceptually  
stretched, possibly, to the point of failure. Or worse - that saying  
"distclean" means two different things to two different people.

I would argue two types of distclean - package and BR. Now, how to  
implement them I leave up to the experts.

Look forward to my book "The Philosophical Underpinnings of DistClean  
and Why The Guardrails of the Abyss Have Been Removed"

Cheers,

Lloyd

[Buildroot] Properly setting up hotplug

[Peter Korsgaard]

>>>>> "Sagaert" == Sagaert Johan <sagaert.johan@skynet.be> writes:

 Sagaert> Hi
 Sagaert> cleaning :
 
 Sagaert> I don't trust the disclean, it most ends op in a mess.

distclean does a rm -rf dl build_<arch> project_build_<arch>/<project>
binaries/<project>, so that's pretty good.

It currently doesn't get rid for toolchain_build_<arch>, but I'll fix
that now.
 
 Sagaert> i am still wondering why they have put dependencies in
 Sagaert> project_build_arm/../ autotools-stamps. instead of in
 Sagaert> build_arm

Because of the project stuff. There's been discussion about getting
rid of that and simply use the external toolchain stuff if you want to
build seperate rootfs'es for similar hw, and I'm seriously considering
doing so.
 
 Sagaert> besides this, there are still othter issues, the libssp.so.0
 Sagaert> gets build but not installed in the target root directory.

Ohh, details please.

-- 
Bye, Peter Korsgaard

[Buildroot] future of project support

[Hamish Moffatt]

On Fri, Apr 17, 2009 at 03:36:01PM +0200, Peter Korsgaard wrote:
> Because of the project stuff. There's been discussion about getting
> rid of that and simply use the external toolchain stuff if you want to
> build seperate rootfs'es for similar hw, and I'm seriously considering
> doing so.

I'm in favour of some simplification. Here's my usage:

I have a few related projects. I want to build them from the same source
tree. Ideally I can have them all built within one check-out, so I can
quickly make a change and test it in multiple projects (without checking
in, updating the other check out etc).

I don't care if everything is rebuilt for each project.. (except the
toolchain possibly). I think the current mix of build_arch /
project_build_arch is a mess, I'd prefer to have everything in
project_build_arch really.



Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] future of project support

[Peter Korsgaard]

>>>>> "Hamish" == Hamish Moffatt <hamish@cloud.net.au> writes:

Hi,

 >> Because of the project stuff. There's been discussion about getting
 >> rid of that and simply use the external toolchain stuff if you want to
 >> build seperate rootfs'es for similar hw, and I'm seriously considering
 >> doing so.

 Hamish> I'm in favour of some simplification. Here's my usage:

 Hamish> I have a few related projects. I want to build them from the
 Hamish> same source tree. Ideally I can have them all built within
 Hamish> one check-out, so I can quickly make a change and test it in
 Hamish> multiple projects (without checking in, updating the other
 Hamish> check out etc).

Have you ever used the out-of-tree build feature? I use it all the
time, and it seems to fit this use case. Simply do make
O=/output/dir/for/project1 and all the build / binaries dirs gets in
/output/dir/for/project1.

 Hamish> I don't care if everything is rebuilt for each project.. (except the
 Hamish> toolchain possibly). I think the current mix of build_arch /
 Hamish> project_build_arch is a mess, I'd prefer to have everything in
 Hamish> project_build_arch really.

Or simply build_arch if we get rid of the project stuff.

-- 
Bye, Peter Korsgaard