OK, so I'm trying to be open minded and deal with yet another version control system.
I've "cloned" the repository and built my mainline. I do not "autogenerate" a version.c file in windows. Build fails missing version.obj. Note that in the windows world, we use Nmake from the MSVC install - no GNU tools required. An aside on Hg... Confirm for me that I basically need to do the following: Create a clone repository: hg clone http://hg.addictivecode.org/wget/mainline Get any changes from mainline into my clone hg pull http://hg.addictivecode.org/wget/mainline Make my src changes, create a "changeset"... And then I'm lost... And as a follow-up question - what does Hg get you above and beyond CVS or SVN? I kind of get the non-centralized aspect of repositories and clones, but I don't understand how changesets and tips work. My thoughts are that there is *one* source of the code (with histories) regardless of SVN, Hg or whatever. Hg's concept of multiple clones and repositories is quite interesting, but doesn't feel right for the remote, non-connected group of developers that wget gathers input from. If we were all behind a firewall or could share out each user's repository, it might make more sense, but I (for one) wouldn't be able to share my repository (NAT'd, firewalled, corporate desktop), so I just don't get it. Chris Christopher G. Lewis http://www.ChristopherLewis.com > -----Original Message----- > From: Micah Cowan [mailto:[EMAIL PROTECTED] > Sent: Saturday, October 13, 2007 4:59 AM > To: Wget > Subject: Re: Version tracking in Wget binaries > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Micah Cowan wrote: > > Hrvoje Niksic wrote: > >> Micah Cowan <[EMAIL PROTECTED]> writes: > > > >>> Among other things, version.c is now generated rather than > >>> parsed. Every time "make all" is run, which also means that "make > >>> all" will always relink the wget binary, even if there > haven't been > >>> any changes. > >> I personally find that quite annoying. :-( I hope there's a very > >> good reason for introducing that particular behavior. > > > > Well, making version.c a generated file is necessary to get the > > most-recent revision for the working directory. I'd like to > avoid it, > > obviously, but am not sure how without making version.c dependent on > > every source file. But maybe that's the appropriate fix. It > shouldn't be > > too difficult to arrange; probably just > > version.c: $(wget_SOURCES) > > or similar. > > version.c is no longer unconditionally generated. The > "secondary" file, > hg-id, which is generated to contain the revision id (and is used to > avoid using GNU's $(shell ...) extension, which autoreconf complains > about), depends on $(wget_SOURCES), and $(LDADD) (so that it properly > includes conditionally-used sources such as http-ntlm.c or gen-md5.c > when applicable). > > This has the advantage that every "make" does not result in > regenerating > version.c, recompiling version.c and relinking wget. It has the > potential disadvantage that, since $(wget_SOURCES) includes version.c > itself, there is the circular dependency: version.c -> hg-id -> > version.c. GNU Make is smart enough to catch that and throw that > dependency out. > > - -- > Micah J. Cowan > Programmer, musician, typesetting enthusiast, gamer... > http://micah.cowan.name/ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHEJb07M8hyUobTrERCE4rAJ9gKXonGN9bRydErVkxtZF8g723CACeLbhD > VYUyd0MnjBdjcRXMSTge0ZE= > =cC2V > -----END PGP SIGNATURE----- >
