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

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.  


Christopher G. Lewis

> -----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
> 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/
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> iD8DBQFHEJb07M8hyUobTrERCE4rAJ9gKXonGN9bRydErVkxtZF8g723CACeLbhD
> VYUyd0MnjBdjcRXMSTge0ZE=
> =cC2V

Reply via email to