Thread: [Cgdb-devel] Cgdb port for Cygwin
Brought to you by:
bobbybrasko,
crouchingturbo
Menu
▾
▴
cgdb-devel
|
From: Ronald Landheer-C. <bly...@us...> - 2003-11-24 17:18:49
|
I've made the first set of changes to my local sandbox to allow out-of-tree building and am about to commit them (or rather: will commit them tomorow morning) to the cygwin package's branch. Are there any objections against me removing the generated files (Makefile.in, configure, etc.) from the branch? They tend to bloat the CVS contents and, for the moment, do not exactly reflect my changes because they're re-created with a different set of Autotools than I will use to make the final package.. (IMHO, no generated files should exist in CVS anyway..). Of course, when merging any changes I make into HEAD, you can keep the (then again re-generated) files if you want :) rlc -- You're out of memory |
|
From: Bob R. <bo...@br...> - 2003-11-24 18:47:11
|
> I've made the first set of changes to my local sandbox to allow out-of-tr= ee=20 > building and am about to commit them (or rather: will commit them tomorow= =20 > morning) to the cygwin package's branch.=20 Great. I am glad to hear it! > Are there any objections against me > removing the generated files (Makefile.in, configure, etc.) from the bran= ch? > They tend to bloat the CVS contents and, for the moment, do not exactly= =20 > reflect my changes because they're re-created with a different set of=20 > Autotools than I will use to make the final package.. (IMHO, no generated > files should exist in CVS anyway..). The original idea was that the user would not need to have autoconf/automake installed in order to get CGDB to build. They could just do ./configure && make. The good thing about that is the user does not have to go get the versions of the tools we are using in order to get CGDB to build. They only need that software in order to change the build system. By removing those files, we would be complicating what the user has to do in order to use CGDB. What does everyone think the best way to go is? Bob Rossi |
|
From: Peter K. <pe...@ko...> - 2003-11-24 19:09:32
|
On Mon, Nov 24, 2003 at 01:47:00PM -0500, Bob Rossi wrote: > > I've made the first set of changes to my local sandbox to allow out-of-= tree=20 > > building and am about to commit them (or rather: will commit them tomor= ow=20 > > morning) to the cygwin package's branch.=20 >=20 > Great. I am glad to hear it! >=20 > > Are there any objections against me > > removing the generated files (Makefile.in, configure, etc.) from the br= anch? > > They tend to bloat the CVS contents and, for the moment, do not exactly= =20 > > reflect my changes because they're re-created with a different set of= =20 > > Autotools than I will use to make the final package.. (IMHO, no generat= ed > > files should exist in CVS anyway..). >=20 > The original idea was that the user would not need to have autoconf/autom= ake > installed in order to get CGDB to build. They could just do ./configure > && make. The good thing about that is the user does not have to go get > the versions of the tools we are using in order to get CGDB to build. > They only need that software in order to change the build system. >=20 > By removing those files, we would be complicating what the user has to > do in order to use CGDB. >=20 > What does everyone think the best way to go is? I say keep generated files out of cvs, but put them into the source tarball when you do a release. That's fairly standard practice. Now that some distributions are packaging cgdb, hopefully it won't be an issue at all. Plus, I say its okay to require specific versions of autoconf/automake if you want to build from CVS. - Peter --=20 Peter D. Kovacs <pe...@ko...> |
|
From: Mike M. <mmu...@cs...> - 2003-11-24 19:13:49
|
I tend to agree with Peter. Although it's convenient to have the generated files present, if it poses a problem, they shouldn't be there. They should definitely be included in the release tarballs. Mike On Mon, 24 Nov 2003, Peter Kovacs wrote: :On Mon, Nov 24, 2003 at 01:47:00PM -0500, Bob Rossi wrote: :> > I've made the first set of changes to my local sandbox to allow out-of-tree :> > building and am about to commit them (or rather: will commit them tomorow :> > morning) to the cygwin package's branch. :> :> Great. I am glad to hear it! :> :> > Are there any objections against me :> > removing the generated files (Makefile.in, configure, etc.) from the branch? :> > They tend to bloat the CVS contents and, for the moment, do not exactly :> > reflect my changes because they're re-created with a different set of :> > Autotools than I will use to make the final package.. (IMHO, no generated :> > files should exist in CVS anyway..). :> :> The original idea was that the user would not need to have autoconf/automake :> installed in order to get CGDB to build. They could just do ./configure :> && make. The good thing about that is the user does not have to go get :> the versions of the tools we are using in order to get CGDB to build. :> They only need that software in order to change the build system. :> :> By removing those files, we would be complicating what the user has to :> do in order to use CGDB. :> :> What does everyone think the best way to go is? : :I say keep generated files out of cvs, but put them into the source :tarball when you do a release. That's fairly standard practice. Now :that some distributions are packaging cgdb, hopefully it won't be an :issue at all. : :Plus, I say its okay to require specific versions of autoconf/automake :if you want to build from CVS. : :- Peter : : :-- :Peter D. Kovacs <pe...@ko...> : |
|
From: Robert L. <rob...@se...> - 2003-11-24 19:30:59
|
On Mon, Nov 24, 2003 at 01:47:00PM -0500, Bob Rossi wrote: > The original idea was that the user would not need to have autoconf/autom= ake > installed in order to get CGDB to build. They could just do ./configure > && make. The good thing about that is the user does not have to go get > the versions of the tools we are using in order to get CGDB to build. > They only need that software in order to change the build system. the user should not be required to have autoconf/automake on her system. ship the generated files. if you want to have an ultimately clean cvs they should not be there either, but just get generated. inreality these files change rarely and could as well be kept in cvs too (this is very convenient for people who just want to hack on some code, but not change the build process) cu robert --=20 Robert Lemmen http://www.semistable.com |
|
From: Ronald Landheer-C. <bly...@us...> - 2003-11-25 11:29:46
|
On Mon, Nov 24, 2003 at 01:47:00PM -0500, Bob Rossi wrote: > > I've made the first set of changes to my local sandbox to allow out-of-tree > > building and am about to commit them (or rather: will commit them tomorow > > morning) to the cygwin package's branch. > Great. I am glad to hear it! > > > Are there any objections against me > > removing the generated files (Makefile.in, configure, etc.) from the branch? > > They tend to bloat the CVS contents and, for the moment, do not exactly > > reflect my changes because they're re-created with a different set of > > Autotools than I will use to make the final package.. (IMHO, no generated > > files should exist in CVS anyway..). > The original idea was that the user would not need to have autoconf/automake > installed in order to get CGDB to build. They could just do ./configure > && make. The good thing about that is the user does not have to go get > the versions of the tools we are using in order to get CGDB to build. > They only need that software in order to change the build system. > > By removing those files, we would be complicating what the user has to > do in order to use CGDB. > > What does everyone think the best way to go is? Personally (but I'm repeating myself), I think a user that wants to build from source should take the source tarball - either the one provided for his/her distribution (which should contain the generated files, of course) or the one released by the project if one for his/her distribution doesn't exist. The released source tarballs should, of course, contain the generated files. A developer working on the project should be able to generate the files, and may or may not do so with the same version of the tools as the person that makes the distribution. I, for one, did most of the porting I did so far on the Cygwin branch on a Gentoo box with a slightly outdated set of Autotools, which doesn't change much functionally (as the configury files for cgdb are more or less garden variety) but it does make a rather significant difference in the generated files, which is transient as the files will finally be generated for Cygwin, on Cygwin, with the latest Autotools. The result is a rather bloated patch (as the one for the previous release) with only very few man-made changes. For info: the diff with all files (generated and man-made) is 253K (7908 lines) in size, w/o ChangeLog entries; the one without the generated files (aclocal.m4, configure and Makefile.in) is 3.7 K (111 lines). The difference of almost 7800 lines in a patch - all of which are generated - seems rather significant to me, especially if someone wants to review the changes I made on the branch to merge them into HEAD: 7800 lines of clutter could easily hide a few lines of bugs. The reason I don't like having generated files in CVS is not only that it bloats the repository - which from an administrators perspective is reason enough - but that it also bloats man-made changes and tends to obfuscate those changes. I don't know how you review changes, but I generally look at the patch before applying it and 7800 lines of generated clutter certainly makes that more difficult. That said, I re-iterate that removing the files from the branch has no impact on HEAD, and as the branch is intended for a Cygwin release which, itself, will contain the necessary (generated) files, it will have no impact on Cygwin-cgdb users either. rlc -- Most people don't need a great deal of love nearly so much as they need a steady supply. |
|
From: Bob R. <bo...@br...> - 2003-11-26 23:22:31
|
> > Are there any objections against me > > removing the generated files (Makefile.in, configure, etc.) from the br= anch? > What does everyone think the best way to go is? Sorry I have been so slow at replying. I have been fixing up the house I just bought. Trying to make it livable by Saturday :). You just have to love diversity and computer science. We currently have 2 for removing the files cygwin packager (Ronald) developer (Peter) 2 for leaving the file debian packager (Robert) developer (Me) 1 who doesn't care developer (Mike) I think it takes 2/3 of the developer's and 3/4 of the packagers to pass an= y=20 CVS legislation. Can someone correct me if I'm wrong? :) Unless, there are some other reasons besides bloating CVS, I would prefer to keep the generated files. Currently, I don't mind having the CVS sandbox be larger as long as the user gets more functionality out of it. Which happens to be the case. I have received several patches from people that fix bugs in CGDB. I don't really want to make them go through extra steps of learning how the build process works, or installing other packages, in order to make simple changes to CGDB. If it turns out that keeping them in the tree is doing harm, we should defiantly remove them. Bob Rossi |
|
From: Ronald Landheer-C. <bly...@us...> - 2003-11-27 11:54:06
|
On Wed, Nov 26, 2003 at 06:22:23PM -0500, Bob Rossi wrote: > > > Are there any objections against me > > > removing the generated files (Makefile.in, configure, etc.) from the branch? > > > What does everyone think the best way to go is? > > Sorry I have been so slow at replying. I have been fixing up the house I > just bought. Trying to make it livable by Saturday :). > > You just have to love diversity and computer science. We currently have > > 2 for removing the files > cygwin packager (Ronald) > developer (Peter) > > 2 for leaving the file > debian packager (Robert) > developer (Me) > > 1 who doesn't care > developer (Mike) > > I think it takes 2/3 of the developer's and 3/4 of the packagers to pass any > CVS legislation. Can someone correct me if I'm wrong? :) > > Unless, there are some other reasons besides bloating CVS, I would > prefer to keep the generated files. Currently, I don't mind having the > CVS sandbox be larger as long as the user gets more functionality out > of it. Which happens to be the case. > > I have received several patches from people that fix bugs in CGDB. I > don't really want to make them go through extra steps of learning how > the build process works, or installing other packages, in order to make > simple changes to CGDB. > > If it turns out that keeping them in the tree is doing harm, we should > defiantly remove them. OK, I'll leave them in :| rlc |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X