On Tue, 2006-07-18 at 11:07 -0700, K. Richard Pixley wrote: > Granted, some of these can be addressed by treating the subprocesses > on scratchbox as though it were a remote host, using remote gdb > protocols, ssh or the like to start the compiles, etc, so there are > alternatives.
Yes. Basically the way to integrate Scratchbox with an IDE is to prefix build command with "scratchbox" (or "/scratchbox/login"). Note that the "/scratchbox/users/$USER/home/$USER" path is visible both inside and outside Scratchbox, which helps when opening the position of an error message etc. > But that's a tedious process to set up by comparison to simply > rebuilding emacs in scratchbox. Or one might naively think. The build failure is due to Emacs's build system. For some reason it uses a hardcoded path to crt1.o. Also, you would have to add X11 libs (and more) to Scratchbox unless you wanted to stick with text mode Emacs. > Well, because there are already several well known concepts by that > name in this context. Notably, the "target" for which a particular > gcc toolchain was configured and compiled, which at this point seems > to have no correlation whatsoever to the scratchbox concept of an > instance of a clean filesystem+toolchain pairing. But it does have correlation. Scratchbox's target is just an extension to the toolchain used with it. A toolchain's target is a machine and Scratchbox's target contains binaries executable on that machine. The reason for the whole "empty filesystem" baggage is because those binaries should not be mixed with other binaries built with different toolchains. The reason why you can have multiple Scratchbox targets per toolchain is of course due to the fact that you can build multiple systems with different contents with a given toolchain. > Ok. So a devkit is really just extra stuff in some conventional > packaging? Yes. > And is it extra stuff in the sense of being part of a target or in the > sense of being part of the globally installed magic stuff? Both? > Neither? Devkit is not part of the contents (the "empty filesystem") of the target. Its tools are just accessible when building software in Scratchbox. Just like gcc and make are. > So /lib/libc.a in one target can be different from /lib/libc.a in > another target? That's the idea. > Is there a way to share portions of the root file system or must those > simply be replicated between targets? I'm thinking here of a slew > of .so's which may be cpu specific, but not necessarily target > specific. No. But you can archive your work and extract it on another target so that you don't have to rebuild/reinstall everything if you are not interested in touching library dependencies. > > 2) which devkits' tools do we need for the development of our system > > Now you've lost me again. It was sounding as though a devkit was > optional and nonexclusive. But this makes it sound like a requirement > and an exclusive one. Sorry. Read that again and think that they are optional. There can be 0..* devkits per target. (In a sense, scratchbox-core is a mandatory devkit because it contains a lot of tools that are always available.) > > 3) how are the binaries built for the target architecture executed > > > Excellent. Yes, this is the info I wasn't finding. Thank you. > > Is there a description of the configuration file? Where is it > located? It is created automatically by sb-conf or sb-menu. The configuration for target X is in file /targets/X.config. > And in the view of a particular scratchbox instance, do these, (and > the home directories), account for all visible files? The following directory hierarchies do not change between targets: /home /scratchbox - contains all tools, including devkits and compilers /targets - physical location of all targets' contents and configs /host_usr - empty place for building your extra host tools (Emacs) The reset change when you select a new target. > So if I have a particular target, say, HOST, how do I determine the > location of the actual gcc or cc1 in use? Well, you don't. :) You should never need to. If you must, you can look into the target's config file and see. > That doesn't help me produce toolchains that can be shared with other > developers or distributed, though. I really want to know where these > things are located and how to build toolchains for scratchbox. Yes, > I've seen the toolchain support stuff, and since it didn't work out of > the box for me it seemed much easier to just build my own rather than > trying to tear apart someone else's build scripts. But, of course, in > order to do that, I need to know about the structure of the file > system being presented and the mechanism by which that presentation is > created. Everything related to toolchain X is located in the directory /scratchbox/compilers/X. Nowadays the preferred way to produce toolchains for Scratchbox is to build an ordinary cross-GCC outside of Scratchbox (or grab a prebuilt one from somewhere) and then convert it to a "foreign toolchain" (read: add Scratchbox-specific bells and whistles) with the help of the sb-toolchains-extras package. We are going to phase out the sb-toolchains build system. timo _______________________________________________ Scratchbox-users mailing list Scratchbox-users@lists.scratchbox.org http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users
