[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scratchbox.org/pipermail/scratchbox-users/attachments/20060718/3cb6e7db/attachment.html