Re: [Scratchbox-devel] Re: [maemo-developers] build system
While trying to build it by hand and also create an ebuild (Gentoo), I've found out that many other things are hard coded and the build process is not that usual (ie: doesn't use autotools and stuff like that). There is any reason? We look forward for your patches... The reason autools isn't used is the same reason gentoo isn't built with autotools - scratchbox is a distribution of collected software, not a singe homogenic application. Hardcoded non-FHS paths are used because FHS directories point to the target directories. If an embedded device developer wants to put applications into /opt (which is common), scratchbox tools cant be in /opt/scratchbox ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] build system
On 7/6/05, Paul Mundt [EMAIL PROTECTED] wrote: On Wed, Jul 06, 2005 at 10:26:37AM -0300, Gustavo Barbieri wrote: I use a system where / doesn't have much space, but I have some spare in /mnt/extra, so I want to install maemo/scratchbox in /mnt/extra/maemo/, however everything is hard coded to /scratchbox. # ln -s /mnt/extra/maemo /scratchbox Unfortunately whoever built the binary packages didn't make them relocatable, but the symlink works as a quick-and-dirty fix. Yes, I know this solution, but: /scratchbox breaks LSB... since it's hardcode, make it to /opt at least. and the build system also doesn't make it easy to change the install prefix. -- Gustavo Sverzut Barbieri --- Computer Engineer 2001 - UNICAMP GPSL - Grupo Pro Software Livre Cell..: +55 (19) 9165 8010 Jabber: [EMAIL PROTECTED] ICQ#: 17249123 MSN: [EMAIL PROTECTED] Skype: gsbarbieri GPG: 0xB640E1A2 @ wwwkeys.pgp.net ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] build system
On Wed, 2005-07-06 at 10:37 -0300, Gustavo Barbieri wrote: On 7/6/05, Paul Mundt [EMAIL PROTECTED] wrote: On Wed, Jul 06, 2005 at 10:26:37AM -0300, Gustavo Barbieri wrote: I use a system where / doesn't have much space, but I have some spare in /mnt/extra, so I want to install maemo/scratchbox in /mnt/extra/maemo/, however everything is hard coded to /scratchbox. # ln -s /mnt/extra/maemo /scratchbox Unfortunately whoever built the binary packages didn't make them relocatable, but the symlink works as a quick-and-dirty fix. Yes, I know this solution, but: /scratchbox breaks LSB... since it's hardcode, make it to /opt at least. and the build system also doesn't make it easy to change the install prefix. The /scratchbox path comes from the upstream Scratchbox.org project. Please file a request at http://bugzilla.scratchbox.org if you wish it to be changed. - Toni ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] build system
On Wed, Jul 06, 2005 at 10:37:19AM -0300, Gustavo Barbieri wrote: On 7/6/05, Paul Mundt [EMAIL PROTECTED] wrote: On Wed, Jul 06, 2005 at 10:26:37AM -0300, Gustavo Barbieri wrote: I use a system where / doesn't have much space, but I have some spare in /mnt/extra, so I want to install maemo/scratchbox in /mnt/extra/maemo/, however everything is hard coded to /scratchbox. # ln -s /mnt/extra/maemo /scratchbox Unfortunately whoever built the binary packages didn't make them relocatable, but the symlink works as a quick-and-dirty fix. Yes, I know this solution, but: /scratchbox breaks LSB... since it's hardcode, make it to /opt at least. Yes, that would be the sensible place, and is incidentally where I keep it on my machine. File a bug against scratchbox on their site if you would like them to do something about it. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] build system
Gustavo Barbieri wrote: While trying to build it by hand and also create an ebuild (Gentoo), I've found out that many other things are hard coded and the build process is not that usual (ie: doesn't use autotools and stuff like that). There is any reason? Scratchbox is a complex piece of software; it's actually closer to an operating system than an application. There are a few reasons why things are like they are: Scratchbox's host tools (including compilers) are dynamic binaries that need to work in the sandbox where the root filesystem is dominated by the contents of the target filesystem. The host tools are linked so that they find correct host libraries from under /scratchbox instead of trying to link against ARM/whatever libraries found in /lib and /usr/lib. The host tools can also be used outside the sandbox environment, so the library location must be the same in either case for that to work. Being able to use the toolchains from outside is handy, but moving the Scratchbox installation directory to a more suitable place is often more important. I have done some preliminary work for making the installation and login process work even when /scratchbox doesn't exist outside the sandbox; the work should be fairly simple to complete. A bigger problem (from my perspective) is the fact that Scratchbox can only be built directly to its installation directory. The tools fail to configure and/or build when things are not in correct places. I worked on this problem last year, but in the end it seemed next to impossible to fix--I don't remember the specific problems anymore. This problem could also be solved by building most of the tools inside the sandbox (like sb-perl-devkit and sb-toolchains are built), but then we'd also have to build all libraries and tools that are used during the build (i.e. Linux from scratch). Using autotools for building Scratchbox would be a bit pointless because the Scratchbox build procedure is not something automake or autoconf solve. Scratchbox is mostly just a set of upstream packages that already have autotools-based build systems; we just have to build them with correct settings (and patches) in the correct order. We use the GAR system[1] which is specifically designed for this. (GAR is a bit messy because it uses make; I'd one day like to replace it with a scons[2]-based build system...) [1] http://www.lnx-bbc.org/garchitecture.html [2] http://www.scons.org/ We (Lauri Leukkunen, Veli Mankinen and myself) have plans[3] for a complete redesign of Scratchbox which (among other things) solves all of the problems you mentioned. We're hoping to write a more elaborate Scratchbox 2.0 design document in near future. But any help in improving the existing versions is naturally welcome. :) [3] http://scratchbox.org/~tsavola/sb2-outline.txt I'm posting this message to scratchbox-devel so that we can continue the discussion on a more suitable mailing list. timo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
