Thanks for the reply, Yaakov, but I guess I wasn't clear enough. I hope this helps more to show the plausibility, and desirability, of this fix. It's not a complete one, I know, as some items that are part of it you're in a better position to figure which methods work best for the environment you do builds, patches in.
Setup.exe unpacks whatever dir structure is inside the -src.tar.bz2 into /usr/src, like the binary packages just get unpacked to /. It's left to the package maker to create the desired structure, deliberately, and there's no need to change setup.exe, but for this flexibility each package maker is required to manually ensure no overwrites on unpack from either type of archive will occur. My method takes advantage of this flexibility to automate this overwrite avoidance for cygport package makers and is the basis for corollary enhancements to further automate package maintenance and updating, at least for the source archives. It's a much harder situation to resolve for the binary package files, as they're highly dependant on design choices of the sources being ported. Requirements for testing binaries run properly after being built prior to packaging are also nebulous, so I don't address them here. It will work as listed, I believe, but the cost is each -src package currently available under releases/ would need repackaging and reuploaded manually. Adding the extra dir to the repository might not be really necessary, but it does provide a common parent dir name whether a checkout occurs from trunk/ or a branches/<name1> or tags/<name2> if those are used in the future. AFAICS, the ports repository holds the bootstrap files which the packages setup.exe references initially get built from, so eventually in that bootstrapping process I'd think somewhere the dir structure setup.exe expects is accounted for so setup.ini can be properly generated. I realize what may be efficient for setup.exe to use isn't necessarily the same as what is easier for a port maintainer or creator to administer, so a one to one correspondance between release/ and trunk/ isn't to be expected, but since this deals with the source files I favor the latter. I use the SVN as the dir structure so that when somebody commits changes to there these changes can be tested, with intermediate files for each phase of a build process going to 'easy to search for' locations that don't disturb the current cygwin installed base, and when verified as building as expected a tested package is ready for uploading. The idea is if you run cygport in a SVN checkout dir, maybe with a special command to trigger bootstrap only operations, it will eventually also produce packages for setup to use just as running 'cygport all' in the dir setup unpacks from a -src.tbz will recreate the packages. This should make life a bit easier for those with commit access to the repository, and for users without it that need to regen a binary package file because their environment differs enough from the default one used to make the downloaded files that regressions crop up. Keeping everything under /usr/src for the intermediate files dirs allows multiple user access on the same machine, rather than using multiple HOME directory entries. Setting up a post-commit script in the repository that looks for special "package changes now tested good" markers can be used to trigger automatic updates of the ftp site directories, regenerating setup.ini and posting to the announce list. Whether this happens per-commit or as a batch per-time-period is, I think, easy enough to setup. The markers can be thought of as a sparse tagging of trunk, or a branch, rather than the entire repository in the tags/ dir and cluttering it. I can think of a few ways how a marker could be stored and detected but which method would be efficient I haven't really explored. By 'easy to search for' I mean that the files at one place in the SVN tree will have their intermediate files at the same place in any other trees, without having to worry those files are mixed in with files of any other package, so in a dual pane file browser you can visually inspect a phase N dir and phase N+1 dir to see that what got put into N+1 corresponds to N as expected, such as .o files built matching to their .c files. Thanks again, Mark ------------------------------------------------------------------------- ---------------------- That's a limitation of setup.exe over which I have no control. It would be nice if setup.exe would unpack a source into /usr/src/PACKAGE_NAME instead of straight into /usr/src, but you'll need to take that up with the Cygwin setup.exe developers if you want to see that changed. The structure of the Ports SVN has nothing to do with getting the sources from setup.exe. If you want to use Ports SVN, then "svn co" it; don't expect to get that layout from the source tarballs. Yaakov Cygwin Ports ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Cygwin-ports-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cygwin-ports-general
