[leaf-devel] Bering-uClibc: development environment assistance ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Moved to devel list... Martin Hejl wrote: snip | For a much more verbose description (one that also includes the how | and not only the what), please see | http://leaf.sourceforge.net/doc/guide/buc-devel.html | That should be enough to get you going. If something is unclear or plain | wrong (happens at times, since the documentation doesn't always keep up | with development), please let us know. | | If you have specific questions, please ask as well. | | I hope that helps. I just started playing with buildtool, which seems pretty slick. I think I have the build environment setup and built without problems (I was able to build ncurses and bash), but I'm a bit unsure of how to proceed with trying to build new packages (ie: vim, rsync, etc). What's the easiest way to 'tinker' with creating a new package? It looks like I need to put the initial package files online via http or viewcvs, and add an appropriate server section to conf/sources.cfg. Is this correct, or is there support for 'local', or file:// type of access, so I could just make a local repository with the source tarball and buildtool config files, and not hassle with network downloads? Thanks, - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCQEjNLywbqEHdNFwRAip9AKDC2zAkJglMGfFGWGyvLEp0zSDddgCfbZnb AmXUUtLFVYfB97abKHI2P5Q= =0iP6 -END PGP SIGNATURE- --- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882alloc_id=15148op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering-uClibc: development environment assistance ???
Am Dienstag, 22. März 2005 17:33 schrieb Charles Steinkuehler: Moved to devel list... Martin Hejl wrote: snip | For a much more verbose description (one that also includes the | how and not only the what), please see | http://leaf.sourceforge.net/doc/guide/buc-devel.html | That should be enough to get you going. If something is unclear | or plain wrong (happens at times, since the documentation doesn't | always keep up with development), please let us know. | | If you have specific questions, please ask as well. | | I hope that helps. I just started playing with buildtool, which seems pretty slick. I think I have the build environment setup and built without problems (I was able to build ncurses and bash), but I'm a bit unsure of how to proceed with trying to build new packages (ie: vim, rsync, etc). What's the easiest way to 'tinker' with creating a new package? It looks like I need to put the initial package files online via http or viewcvs, and add an appropriate server section to conf/sources.cfg. Is this correct, or is there support for 'local', or file:// type of access, so I could just make a local repository with the source tarball and buildtool config files, and not hassle with network downloads? A quick'n'dirty solution is to create a directory for your app in buildtool/sources like buildtool/sources/rsync Copy your source tgz into that dir and create there buildtool.mk and buildtool.cfg (you may copy existing ones and change as needed). You'll have to add the new package to conf/sources.cfg like any other - don't bother about server/network stuff - with all needed files in sources/yourpackage it will not try to download again. If you like, I can send you the rsync setup and the corresponding entry for sources.cfg as example. kp --- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_idh82alloc_id148op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering-uClibc: development environment assistance ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 K.-P. Kirchdörfer wrote: | Am Dienstag, 22. März 2005 17:33 schrieb Charles Steinkuehler: snip | What's the easiest way to 'tinker' with creating a new package? It | looks like I need to put the initial package files online via http | or viewcvs, and add an appropriate server section to | conf/sources.cfg. | | Is this correct, or is there support for 'local', or file:// type | of access, so I could just make a local repository with the | source tarball and buildtool config files, and not hassle with | network downloads? | | A quick'n'dirty solution is to create a directory for your app in | buildtool/sources | like | buildtool/sources/rsync | | Copy your source tgz into that dir and create there buildtool.mk and | buildtool.cfg (you may copy existing ones and change as needed). | | You'll have to add the new package to conf/sources.cfg like any other | - don't bother about server/network stuff - with all needed files | in sources/yourpackage it will not try to download again. Thanks...I didn't realize it wouldn't try downloading if the files are already there. So far, the only thing that seems odd about buildtool is the centralized file with all the servers, sources, and packages (conf/sources.cfg). The files for building each package are already seperated per-package, so it seems like this should be multiple files and/or directories as well, ie: ~ conf/servers- File with server entries ~ conf/pagkages/ - Directory ~ conf/packages/mypkg - Single entry ~ conf/sources/ - Directory ~ conf/sources/mysrc - Single entry ...but I have no idea how easy/hard this would be in perl (yes, I've fallen to the point of suggesting new features/functions w/o offering any coding assistance! :). It just seems that having to modify the entire sources.cfg file to add/remove a package is going to get cumbersome eventually... | If you like, I can send you the rsync setup and the corresponding | entry for sources.cfg as example. Please do. Also, what's the preferred method to provide files for a new package so they can be included in CVS? A tgz file of sources/pkg and a diff of conf/sources.cfg, or some other method? - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCQFA6LywbqEHdNFwRAnrXAKDhQBpehDViDfZdaz2VHDhdtprFSQCfUEKp LVs2h5j7MZN1B4OdQPqAvLU= =oWQ9 -END PGP SIGNATURE- --- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882alloc_id=15148op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering-uClibc: development environment assistance ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Hejl wrote: | Hi Charles, snip | So far, the only thing that seems odd about buildtool is the centralized | file with all the servers, sources, and packages (conf/sources.cfg). The | files for building each package are already seperated per-package, so it | seems like this should be multiple files and/or directories as well, ie: | | ~ conf/servers- File with server entries | ~ conf/pagkages/ - Directory | ~ conf/packages/mypkg - Single entry | ~ conf/sources/ - Directory | ~ conf/sources/mysrc - Single entry | I agree that mixing the servers with the sources wasn't a terribly good | idea - but then, the servers in conf/sources.cfg should really only be | sourceforge servers (since that's where buildtool gets the buildtool.cfg | from), so that part should be fairly static. | The split between sources and packages doesn't make much sense to me | right now - mainly because the difference between sources and packages | is very muddled at the moment (the only program that actually makes | some use of that info is buildpacket.pl - so if we defined everything as | package it would work the same way it does right now). But that may | change some time soon as well (or maybe it has already, I've not managed | to stay up to date with Arne's latest changes/scripts). I'm less worried about the packages/sources issue than splitting out the various packages (more below). | I guess the reasoning was to keep things simple and avoid instances | where files weren't kept in sync. Plus historical reasons (things were | stored in a similar manner in the original, make-based buildtool from | uClibc, which we adapted to work for our needs). | | ...but I have no idea how easy/hard this would be in perl (yes, I've fallen | to the point of suggesting new features/functions w/o offering any coding | assistance! :). It just seems that having to modify the entire sources.cfg | file to add/remove a package is going to get cumbersome eventually... | I'm sure it will be at some point. But I'm not sure if keeping several | small files up to date is going to be easier in the long run (not for | adding/removing, but for other kinds of maintenance - new dependencies, | splits of packages and so on). I guess it isn't pretty either way. I'm looking at this from the perspective of a 'power' end user, who would like to tweak some things, but be able to easily stay current on files I choose not to modify. With all package/source statements in a single big file, it seems like it would be harder to use CVS or other versioning software to track changes I've made to the release versions. Examples of things that it would be nice to be able to setup: - - Add package(s) (ie: current vim, rsync, qmail discussions) - - Customize package(s) (ie: unique compile-time options or similar) - - Re-target downloads to a local repository or mirror (to verify complete independence from SF or leaf-project.org, and to control exactly which version(s) of packages are used for an 'in-house' release). - - Easily update a modified project to use new data from the SF CVS archives if/when it becomes available It may be possible (or even easy!) to do this with the current config file, but I didn't immediately see how... - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCQGbJLywbqEHdNFwRAhHgAKDMK9OuC5foNly2WNh8c5nCP8h5nwCggd5g PDrVbFern39w4LixRUvqPsg= =UKhW -END PGP SIGNATURE- --- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882alloc_id=15148op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Website
Everyone, Please notify me if any of our pages don't display in mozilla/firefox or opera, so I can fix them. I just fixed bering-uclibc page 1 and 7. Neither was valid, and page one wasn't displaying in mozilla. -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882alloc_id=15148op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering-uClibc: development environment assistance ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Hejl wrote: | - - Customize package(s) (ie: unique compile-time options or similar) | Well, as long as you don't want upstream changes to be integrated in | your modified version (see below for that topic), you can do that by | separating the sourcing from the build - run buildtool.pl source | packagename first, make your modifications, run buildtool.pl srcclean | packagename (to make sure all your changes are taken into | consideration, especially if autoconf is incolved). | After that, run ./buildtool.pl build packagename, the sources should | be compiled including your changes. | | But this approach doesn't work for integrating upstream changes into | your setup. Thinking about this some more, I think this could be handled like a 'new' package that would start as a 'clone' of an existing package (ie: myash instead of ash). Local mods could be handled with CVS or SVN the same way you'd track vendor releases. | - - Re-target downloads to a local repository or mirror (to verify complete | independence from SF or leaf-project.org, and to control exactly which | version(s) of packages are used for an 'in-house' release). | That should actually be possible, at least for the packages we've | cleaned up already. Once everything is cleaned up, there should not be | any redundant server definitions - so changing the cvs-sourceforge | server definition in conf/sources.cfg to point to your mirror should | make every package definition use that mirror server (at least, where | cvs-sourceforge is used, and where we've removed all redundancies - if | you spot a package where this isn't the case, please let us know). Do you mean like how bash/buildtool.cfg has a Server cvs-sourceforge section, but etc/buildtool.cfg doesn't? If so, I've provided a grep of all app/pkg/buildtool.cfg files that contain a Server tag (circa March 14) after my sig. The checkout of the apps directory took less than a minute...it's occasionally handy to have the full CVS archive available on a local machine!. :) snip | I hope that clarifies a bit. Yes...thanks for all the pointers! - -- Charles Steinkuehler [EMAIL PROTECTED] naibed:/home/leaf/src/bering-uclibc/apps# grep -A 1 'Server' */buildtool.cfg ash/buildtool.cfg:Server cvs-sourceforge ash/buildtool.cfg- Type = viewcvs - -- automake/buildtool.cfg:Server gnu automake/buildtool.cfg- Type = ftp - -- bash/buildtool.cfg:Server cvs-sourceforge bash/buildtool.cfg- Type = viewcvs - -- beep/buildtool.cfg:Server cvs-sourceforge beep/buildtool.cfg- Type = viewcvs - -- bison/buildtool.cfg:Server cvs-sourceforge bison/buildtool.cfg- Type = viewcvs - -- bpalogin/buildtool.cfg:Server cvs-sourceforge bpalogin/buildtool.cfg- Type = viewcvs - -- bridge-utils/buildtool.cfg:Server cvs-sourceforge bridge-utils/buildtool.cfg- Type = viewcvs - -- buildenv/buildtool.cfg:Server ftp.gnu.org buildenv/buildtool.cfg-Type = http - -- buildenv/buildtool.cfg:Server gcc.mirror buildenv/buildtool.cfg- Type = ftp - -- buildenv/buildtool.cfg:Server cvs-sourceforge buildenv/buildtool.cfg-Type = viewcvs - -- buildenv/buildtool.cfg:Server kernel.org buildenv/buildtool.cfg- Type = http - -- buildenv/buildtool.cfg:Server uclibc.org buildenv/buildtool.cfg-Type = http - -- flex/buildtool.cfg:Server cvs-sourceforge flex/buildtool.cfg- Type = viewcvs - -- hdsupp/buildtool.cfg:Server cvs-sourceforge hdsupp/buildtool.cfg-Type = viewcvs - -- iptraf/buildtool.cfg:Server cvs-sourceforge iptraf/buildtool.cfg- Type = viewcvs - -- kgcc/buildtool.cfg:Server cvs-sourceforge kgcc/buildtool.cfg- Type = viewcvs - -- kgcc/buildtool.cfg:Server gnu kgcc/buildtool.cfg- Type = ftp - -- libgcc/buildtool.cfg:Server cvs-sourceforge libgcc/buildtool.cfg- Type = viewcvs - -- libgmp3/buildtool.cfg:Server cvs-sourceforge libgmp3/buildtool.cfg- Type = viewcvs - -- libpthread/buildtool.cfg:Server cvs-sourceforge libpthread/buildtool.cfg- Type = viewcvs - -- libtool/buildtool.cfg:Server cvs-sourceforge libtool/buildtool.cfg- Type = viewcvs - -- linux/buildtool.cfg:Server kernel.org linux/buildtool.cfg-Type = http - -- local/buildtool.cfg:Server cvs-sourceforge local/buildtool.cfg- Type = viewcvs - -- log/buildtool.cfg:Server cvs-sourceforge log/buildtool.cfg- Type = viewcvs - -- lrpstat/buildtool.cfg:Server cvs-sourceforge lrpstat/buildtool.cfg- Type = viewcvs - -- mawk/buildtool.cfg:Server cvs-sourceforge mawk/buildtool.cfg- Type = viewcvs - -- mgetty/buildtool.cfg:Server cvs-sourceforge mgetty/buildtool.cfg- Type = viewcvs - -- nasm/buildtool.cfg:Server cvs-sourceforge nasm/buildtool.cfg- Type = viewcvs - -- ncurses/buildtool.cfg:Server cvs-sourceforge ncurses/buildtool.cfg- Type = viewcvs - -- net-tools/buildtool.cfg:Server cvs-sourceforge net-tools/buildtool.cfg- Type = viewcvs - -- ntp/buildtool.cfg:Server cvs-sourceforge ntp/buildtool.cfg- Type = viewcvs - -- nttcp/buildtool.cfg:Server cvs-sourceforge nttcp/buildtool.cfg- Type = viewcvs - --
