Re: [leaf-devel] Bering-uClibc: development environment assistance ???
Am Dienstag, 22. März 2005 21:56 schrieb Charles Steinkuehler: 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!. :) Thx for the list; we've updated (hopefully) all packages now. kp --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=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 ???
Hi Charles, 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) I guess that's as easily done with this scheme as with any other (provided you have write access to CVS if you want to make things public). I rarely ever have a version of conf/sources.cfg that looks exactly like the one in CVS (that's what CVS is best at, afterall - merging upstream changes into a locally modified file. As long as one remembers not to add stuff to the end (since that causes conflicts if changes are made to the end of a file upstream as well), everything should be fine). - - 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. - - 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). - - Easily update a modified project to use new data from the SF CVS archives if/when it becomes available I presume you're referring to something like making changes to a buildtool.mk file locally, and having upstream changes be merged into your files upon request (just like it's done with conf/sources.cfg). Unfortunately that's not possible (I've cursed that a couple of times too), at least not within buildtool (since buildtool simply downloads files via wget). What _is_ possible (even though it requires a little more manual work) is to keep a checked out copy of our apps tree (where most of the stuff comes from anyway), make changes there and then manually copy your changes to buildtool/source/packagename/ I admit it is cumbersome and somewhat error-prone, but that way one can maintain local modifications and still benefit from upstream changes. It may be possible (or even easy!) to do this with the current config file, but I didn't immediately see how... Well, I don't claim that those workarounds are simple (or that they should be obvious to somebody trying to learn to use buildtool). Buildtool wasn't designed knowing all the requirements that would come up with more and more people using it (and that's even more true for buildpacket.pl, which started out as a simple 20 line script to automate the repetitive and error prone task of putting stuff into lrp files) - it developed in a somewhat evolutionary process, and it shows. Many things aren't terribly consistent, and we'd probably do quite a few things differently, if we were imlementing buildtool/buildpacket knowing what we know now. But whatthose two tools do is to automate building a source (and an lrp package with buildpacket), thus enabling more people to compile the programs, letting the Bering uclibc developers concentrate more on getting the compile settings just right and making updated to new upstream versions (of an application) much easier. Ideally, all that is needed to update to a new version is to replace the filename in buildtool.cfg, change the directory name in buildtool.mk and rebuild. I hope that clarifies a bit. Martin --- 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 ???
On Tue, Mar 22, 2005 at 09:03:40PM +0100, Martin Hejl wrote: - - 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). - - Easily update a modified project to use new data from the SF CVS archives if/when it becomes available I presume you're referring to something like making changes to a buildtool.mk file locally, and having upstream changes be merged into your files upon request (just like it's done with conf/sources.cfg). Unfortunately that's not possible (I've cursed that a couple of times too), at least not within buildtool (since buildtool simply downloads files via wget). What _is_ possible (even though it requires a little more manual work) is to keep a checked out copy of our apps tree (where most of the stuff comes from anyway), make changes there and then manually copy your changes to buildtool/source/packagename/ I admit it is cumbersome and somewhat error-prone, but that way one can maintain local modifications and still benefit from upstream changes. I don't know whether this information is useful, but I have done something along the lines of above. I have a local checkout of the cvs tree (buildtool and apps) and I changed the sourceforge-cvs server in the buildtool config to direct to my local apps checkout. In this tree I have some local modifications to packages and also added some packages of my own. This works without problems: I can use the 'buildtool.pl build package' command and it downloads the sources from my local cvs-checkout without any further configuration or me having to make changes to sourced packages. Furthermore I suppose that in this way you could also easily merge new upstream versions with your locally modified sources. Only thing that you have to think about then is, that you remove the downloaded sources before you try to rebuild a package. Jaap --- 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 ???
Hi Charles, I see kp already responded :-) | 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. Well, that behaviour can be changed in conf/buildtool.conf (with the OverwriteFiles setting). Normally, downloading files again is the smart thing to do - but unfortunately, with the download issues SF has had lately, this can also lead to corrupted archives (and errors trying to extract them later on). I guess there's no perfect solution (other than making wget download the file again and again until it thinks it got the whole file - which, as far as I know, is being worked on at the moment). 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 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. 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? A tgz with everything bundled up together would work be perfect. For larger sources, I guess a link to the original source would be best (few people like having the kernel source in their inbox :-)) The changes to conf/sources.cfg need not necessarily be a diff (but then, creating a diff against the current version in CVS simply by issuing cvs diff conf/sources is probably easiest for everybody anyway). I hope that helps. Pointers inaccurate/wrong parts of the docs are always appreciated (I just can't promise I'll fix things immediately - I'll be on holiday over and the week after easter). Martin --- 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 ???
On Tue, 2005-03-22 at 11:04 -0600, Charles Steinkuehler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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... nothing to do in perl at all... We are using Config::General, which supports includes like: include server.cfg ... that's all... --arne Arne Bernin [EMAIL PROTECTED] --- 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 18:04 schrieb Charles Steinkuehler: 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... Good point - sources.cfg becomes somewhat too big - it's been good to start with buildtool - but I can see improvements... | If you like, I can send you the rsync setup and the corresponding | entry for sources.cfg as example. Please do. Will do off-list. 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? Every LEAF developer has write access to our cvs contrib repositories (buildtool setup and sources as well as lrp's). A diff for sources.cfg send by mail - either private or on leaf-devel, should be enough. Lrp's committed to contrib section will be added to the packages page on LEAF Bering-uClibc pages as well. We can also offer you access to our complete cvs tree (includes write access to buildtool :)). 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 ???
On Tue, 2005-03-22 at 10:01, K.-P. Kirchdrfer wrote: Am Dienstag, 22. Mrz 2005 18:04 schrieb Charles Steinkuehler: 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? Every LEAF developer has write access to our cvs contrib repositories (buildtool setup and sources as well as lrp's). A diff for sources.cfg send by mail - either private or on leaf-devel, should be enough. Lrp's committed to contrib section will be added to the packages page on LEAF Bering-uClibc pages as well. We can also offer you access to our complete cvs tree (includes write access to buildtool :)). K.-P., As a project admin Charles has global write access in our repository. http://cvs.sourceforge.net/viewcvs.py/leaf/CVSROOT/avail?rev=1.44view=auto # Complete repository access for project admins avail|cstein, ddouthitt, ericw, guitarlynn, jdnewmil, kapeka, mhnoyes, rayolsz -- 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 Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_idh83alloc_id149op=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 Mike Noyes wrote: | On Tue, 2005-03-22 at 10:01, K.-P. Kirchdrfer wrote: | We can also offer you access to our complete cvs tree (includes write | access to buildtool :)). | | K.-P., | As a project admin Charles has global write access in our repository. But I'd still prefer to have one of the more regular Bering-uClibc developers check in any changes...at least until I'm more comfortable with the buildtool enviornment, doing a lot more uClibc development work, or both. ...besides, I've been using subversion for so long now (part of my day job), I might not remember how to do the CVS command line thing. :) - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCQZoeLywbqEHdNFwRAvXoAKD2FNRbiRYvLo+S/e20UmCoo4JqZgCg8jp0 LzLwPTaaVGCeiLwUVi6FeYw= =+QTn -END PGP SIGNATURE- --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=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 Mittwoch, 23. März 2005 17:32 schrieb Charles Steinkuehler: Mike Noyes wrote: | On Tue, 2005-03-22 at 10:01, K.-P. Kirchdörfer wrote: | We can also offer you access to our complete cvs tree (includes | write access to buildtool :)). | | K.-P., | As a project admin Charles has global write access in our | repository. But I'd still prefer to have one of the more regular Bering-uClibc developers check in any changes...at least until I'm more comfortable with the buildtool enviornment, doing a lot more uClibc development work, or both. Ok. ...besides, I've been using subversion for so long now (part of my day job), I might not remember how to do the CVS command line thing. :) You may train again on your leaf devel cvs tree and we can checkout from there :) But via mail will be fine as well. kp --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_idh83alloc_id149op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[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
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 - --
