Re: [Scratchbox-users] Building from source...

[K. Richard Pixley]

Timo Savola wrote: On Mon, 2006-07-17 at 10:58 -0700, K. Richard Pixley wrote: Well, ok. The first thing I tried to do in scratchbox didn't work, namely, building a "native" emacs using the HOST compiler so that I have a reasonable IDE available. You can run Emacs on your host system (= outside of Scratchbox) and edit files there. You can create a symlink to your Scratchbox home directory (/scratchbox/users/$USER/home/$USER) to make things easier. If you want to open files for editing from within Scratchbox, you can use emacsclient (do "M-x server-start" in your Emacs before using it). Yes, thank you.  That doesn't help for things like M-x compile, M-x next-errror, M-x gdb, M-x shell, etc, though.  At that point emacs is pretty much just reduced to being a text editor rather than a full fledged IDE.  And I have to manually translate from error messages in one window into file and line in another.  Single stepping becomes a chore, etc. 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.  But that's a tedious process to set up by comparison to simply rebuilding emacs in scratchbox.  Or one might naively think. So far I don't even understand what a "devkit" is. I get the idea that there are different toolchains, one selects a toolchain and builds a "target" out of it. And that any particular instance of scratchbox has one "target", (very poor choice of names, btw), active at any one time. If you don't understand what a target is, how can you judge that it's badly named? :) 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. By default Scratchbox comes with general-purpose (build) tools (such as make). A devkit provides special-purpose (build) tools (such as dpkg, or RPM build tools). They are not (usually) related to cross-compilers. Ok.  So a devkit is really just extra stuff in some conventional packaging? 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? But I really have no idea what's involved in a "target" aside from the illusion of a cross compiler. Target is: 1) an empty filesystem for building your system into So /lib/libc.a in one target can be different from /lib/libc.a in another target? 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. 2) a configuration file for Scratchbox to know what to use for it The target configuration defines three (or four) important things: 1a) which compiler to use 1b) what is the target CPU architecture (defined by the compiler) 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. 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? And in the view of a particular scratchbox instance, do these, (and the home directories), account for all visible files?  I don't see where the real compiler is located, I only see the wrappers. The cross-compilers are located in the subdirectories of /scratchbox/compilers. The wrapper executes the correct one based on the target configuration. So if I have a particular target, say, HOST, how do I determine the location of the actual gcc or cc1 in use? I also don't see where the headers or libraries are intended to be located, either when a "target" is active or not. GCC-based cross-toolchains include kernel and C-library header files so you don't really have to care about them. If you want to install additional header files (along with a library you're using), just install them normally to /usr/include. 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. This is helpful, though.  Thank you. --rich

_______________________________________________
Scratchbox-users mailing list
Scratchbox-users@lists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users