RE: version.c take two
Micah -
I haven't tested this yet, but I've been pondering on the impact of having
a dependency on Hg for the actual build process of Wget. Seems like an
awful lot of trouble for a product that in the past has only needed
Make|Nmake and a C compiler.
Is it possible with Hg to create a file that consists of the TIP Output?
We could then echo this back through this section of the make file rather
then using Hg to create it.
What I'm concerned with is someone who downloads the source from a
zip/tarball. Requiring them to have Make|Nmake and a C compiler is
reasonable. Requiring a source control tool (Hg, svn, etc) is not.
Chris
Christopher G. Lewis
http://www.ChristopherLewis.com
-Original Message-
From: Micah Cowan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 16, 2007 6:07 PM
To: wget@sunsite.dk
Cc: Gisle Vanem; Christopher G. Lewis
Subject: Re: version.c take two
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Micah Cowan wrote:
Gisle and Chris, you should be able to write this rule in your
Makefiles. Something like:
version.c: $(SOURCES)
echo 'const char *version_string = @VERSION@' $@
-hg log -r tip --template=' ({node|short})\n' $@
echo ';' $@
Actually, the hg line ought to be:
-hg log -r . --template=' ({node|short})\n' $@
As the user may not necessarily be building from tip. If
closing stderr
or directing it to the equivalent of /dev/null (2NULL?) is
possible,
that should also be included.
- --
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
iD8DBQFHFUQu7M8hyUobTrERCJORAJ4uOqqiuBCyjqGJMnBWIy8xlOeZ/wCggYTt
Saas407pZa3Xpb9joJcxEts=
=kX7O
-END PGP SIGNATURE-
smime.p7s
Description: S/MIME cryptographic signature
Re: version.c take two
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Guess I was forgetting to hit Reply-All today... resent to list. Christopher G. Lewis wrote: Micah - I haven't tested this yet, but I've been pondering on the impact of having a dependency on Hg for the actual build process of Wget. Seems like an awful lot of trouble for a product that in the past has only needed Make|Nmake and a C compiler. No dependency: that's what the - at the beginning of the line is for. If hg is not present, it just says 1.12-devel. Is it possible with Hg to create a file that consists of the TIP Output? We could then echo this back through this section of the make file rather then using Hg to create it. I don't think so... at any rate, we don't want the tip, we want the currently checked-out revision. Note, FWIW, that Subversion also lacks a means of putting the latest revision directly into a file, and requires you to use svnversion to write to a file (http://subversion.tigris.org/faq.html#version-value-in-source). What I'm concerned with is someone who downloads the source from a zip/tarball. Requiring them to have Make|Nmake and a C compiler is reasonable. Requiring a source control tool (Hg, svn, etc) is not. Absolutely. And while I'll miss the information, I'm not going to force people to grab Hg just for that. However, most people who will be downloading source tarballs, zip files, etc, will be downloading from us, and we have some control over the process. AIUI, I believe I can hook the archive-generation from hg, and have it add or modify a file to include the tag. I could modify Makefile.am to use hg when it's available, and fallback to the file if present. As to official or alpha distribution tarballs, those will have otherwise-identifying information, and will not include the revision information. - -- 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 iD8DBQFHFmZD7M8hyUobTrERCKP0AJ9gm3b+X4KN1lB2CsLY8YA/54sPeQCfQjYg HxTe6lOERMLzHQD5gwj7Koo= =DEuF -END PGP SIGNATURE-
Re: version.c take two
Micah Cowan [EMAIL PROTECTED] writes:
version.c: $(wget_SOURCES) $(LDADD)
printf '%s' 'const char *version_string = @VERSION@' $@
-hg log -r tip --template=' ({node|short})' $@
printf '%s\n' ';' $@
printf is not portable to older systems, but that may not be a
problem anymore. What are the current goals regarding portability?
Re: version.c take two
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hrvoje Niksic wrote:
Micah Cowan [EMAIL PROTECTED] writes:
version.c: $(wget_SOURCES) $(LDADD)
printf '%s' 'const char *version_string = @VERSION@' $@
-hg log -r tip --template=' ({node|short})' $@
printf '%s\n' ';' $@
printf is not portable to older systems, but that may not be a
problem anymore. What are the current goals regarding portability?
GNU, modern Unixen, and Windows systems (in that order) take priority,
but portability to other systems is desirable if it's not out of the way.
I may take liberties with the Make environment, and assume the presence
of a GNU toolset, though I'll try to avoid that where it's possible.
In cases like this, printf is much more portable (in behavior) than
echo, but not as dependable (on fairly old systems) for presence;
however, it's not a difficult tool to obtain, and I wouldn't mind making
it a prerequisite for Wget (on Unix systems, at any rate). In a pinch,
one could write an included tool (such as an echo command that does
precisely what we expect) to help with building. But basically, if it's
been in POSIX a good while, I'll probably expect it to be available for
the Unix build.
- --
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
iD8DBQFHFHFV7M8hyUobTrERCDG3AJ0WGcRcE9423lSXcasZ5uTxS2HXMACfQqe8
vI1aTSxAHqPrxQPZuTIzpjM=
=gXYM
-END PGP SIGNATURE-
Re: version.c take two
On Tue, 16 Oct 2007, Micah Cowan wrote: I may take liberties with the Make environment, and assume the presence of a GNU toolset, though I'll try to avoid that where it's possible. Well, the issue has been resolved one way or another with many GNU packages, including the core ones such as GCC, which generally try to be as much portable as possible. It is always worth investigating what others have done and copying the good examples. Please also note the autoconf manual has chapters on shell and make portability issues which provide examples how to do many things in a reliable way. In cases like this, printf is much more portable (in behavior) than echo, but not as dependable (on fairly old systems) for presence; however, it's not a difficult tool to obtain, and I wouldn't mind making it a prerequisite for Wget (on Unix systems, at any rate). In a pinch, one could write an included tool (such as an echo command that does precisely what we expect) to help with building. But basically, if it's been in POSIX a good while, I'll probably expect it to be available for the Unix build. You better avoid the hassle of compiling any code to be run on the build system by any measures unless absolutely necessary or you risk falling down into a hole of horrible traps and riddles once you start cross-compiling. Maciej
Re: version.c take two
Micah Cowan [EMAIL PROTECTED] writes: I may take liberties with the Make environment, and assume the presence of a GNU toolset, though I'll try to avoid that where it's possible. Requiring the GNU toolset puts a large burden on the users of non-GNU systems (both free and non-free ones). Please remember that for many Unix users and sysadmins Wget is one of the core utilities, to be compiled very soon after a system is set up. Each added build dependency makes Wget that much harder to compile on a barebones system. In cases like this, printf is much more portable (in behavior) than echo, but not as dependable (on fairly old systems) for presence; however, it's not a difficult tool to obtain, and I wouldn't mind making it a prerequisite for Wget (on Unix systems, at any rate). In a pinch, one could write an included tool (such as an echo command that does precisely what we expect) to help with building. But basically, if it's been in POSIX a good while, I'll probably expect it to be available for the Unix build. Such well-intended reasoning tends to result with a bunch reports about command/feature X not being present on the reporter's system, or about a bogus version that doesn't work being picked up, etc. But maybe the times have changed -- we'll see.
Re: version.c take two
Micah Cowan wrote:
I've improved the generation of version.c, removing the intermediate
generation of an hg-id file and using a more portable replacement for
hg id | cut -d ' ' -f 1 (can be used on Windows and MS-DOS).
The relevant lines in src/Makefile.am are now:
version.c: $(wget_SOURCES) $(LDADD)
printf '%s' 'const char *version_string = @VERSION@' $@
-hg log -r tip --template=' ({node|short})' $@
printf '%s\n' ';' $@
(The printf commands aren't portable to Windows AFAIK, but this should
be easier to adapt, at any rate. Note that echo -n is not a portable
method for suppressing newlines in echo's output.)
Gisle and Chris, you should be able to write this rule in your
Makefiles. Something like:
version.c: $(SOURCES)
echo 'const char *version_string = @VERSION@' $@
-hg log -r tip --template=' ({node|short})\n' $@
echo ';' $@
This particular usage should actually be portable across all varying
implementations of Unix echo, as well (so maybe I'll use it too--though
printf is still probably a reasonable expectation, and I may well
require it in the future). It takes advantage of C's string-literal
concatenation. The results will be an eyesore, but will work.
Note that if version.c is in SOURCES, there is still a recursive
dependency; if this is a problem for your build system, you may want to
remove version.obj from OBJS, and add it directly to the command to link
wget.exe.
--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
signature.asc
Description: OpenPGP digital signature
Re: version.c take two
Hrvoje Niksic wrote: Micah Cowan [EMAIL PROTECTED] writes: I may take liberties with the Make environment, and assume the presence of a GNU toolset, though I'll try to avoid that where it's possible. Requiring the GNU toolset puts a large burden on the users of non-GNU systems (both free and non-free ones). Please remember that for many Unix users and sysadmins Wget is one of the core utilities, to be compiled very soon after a system is set up. Each added build dependency makes Wget that much harder to compile on a barebones system. Alright; I'll make an extra effort to avoid non-portable Make assumptions then. It's just... portable Make _sucks_ (not that non-portable Make doesn't). In cases like this, printf is much more portable (in behavior) than echo, but not as dependable (on fairly old systems) for presence; however, it's not a difficult tool to obtain, and I wouldn't mind making it a prerequisite for Wget (on Unix systems, at any rate). In a pinch, one could write an included tool (such as an echo command that does precisely what we expect) to help with building. But basically, if it's been in POSIX a good while, I'll probably expect it to be available for the Unix build. Such well-intended reasoning tends to result with a bunch reports about command/feature X not being present on the reporter's system, or about a bogus version that doesn't work being picked up, etc. But maybe the times have changed -- we'll see. Given that there is no portable way to avoid newlines with echo, or to depend on the results of including a backslash in its argument, it may be hard to avoid, depending on what we need it for (with my last revision of the Make rule, however, I've avoided it for this specific purpose). Any modern Unix had pretty dang well include it. Non-modern Unixen won't generally be needing to bootstrap, I'd think (and probably already include older versions of wget anyway). Thanks for the input, Hrvoje. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: version.c take two
Micah Cowan [EMAIL PROTECTED] writes: Alright; I'll make an extra effort to avoid non-portable Make assumptions then. It's just... portable Make _sucks_ (not that non-portable Make doesn't). It might be fine to require GNU make if there is a good reason for it -- many projects do. But requiring random bits and pieces of the GNU toolchain, such as one or more of GNU Bash, GNU grep, GNU tar, or, well, printf :-), in most cases simply causes annoyance for very little added value. Junior developers, or those only exposed to Linux, frequently simply assume that everyone has access to the tools they use on their development system, and fail to document that assumption. I'm sure we can do better than that.
Re: version.c take two
Hrvoje Niksic wrote: Micah Cowan [EMAIL PROTECTED] writes: Alright; I'll make an extra effort to avoid non-portable Make assumptions then. It's just... portable Make _sucks_ (not that non-portable Make doesn't). It might be fine to require GNU make if there is a good reason for it -- many projects do. But requiring random bits and pieces of the GNU toolchain, such as one or more of GNU Bash, GNU grep, GNU tar, or, well, printf :-), in most cases simply causes annoyance for very little added value. Junior developers, or those only exposed to Linux, frequently simply assume that everyone has access to the tools they use on their development system, and fail to document that assumption. I'm sure we can do better than that. Oh, I quite agree. Sorry, I should have been more clear. (And I still don't think printf should qualify as part of the GNU toolchain ;) ...it's been part of POSIX for a good long time.) I was mostly talking about GNU Make, I think, and little else. Basically, if it's not POSIX, I doubt I'll use it, and I'll tend to not use it beyond how POSIX says it should work, unless I _know_ that the extension I'm using is portable anyway. And even POSIX isn't perfect, many systems fail to conform to it in various ways. I was recently surprised to find that the awk Ubuntu ships with by default (mawk), does not support POSIX character classes ([[:space:]] etc), and had to modify the fun little script I use to colorize include the shell's joblist in the prompt (http://micah.cowan.name/hg/promptjobs/). -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: version.c take two
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Micah Cowan wrote:
Gisle and Chris, you should be able to write this rule in your
Makefiles. Something like:
version.c: $(SOURCES)
echo 'const char *version_string = @VERSION@' $@
-hg log -r tip --template=' ({node|short})\n' $@
echo ';' $@
Actually, the hg line ought to be:
-hg log -r . --template=' ({node|short})\n' $@
As the user may not necessarily be building from tip. If closing stderr
or directing it to the equivalent of /dev/null (2NULL?) is possible,
that should also be included.
- --
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
iD8DBQFHFUQu7M8hyUobTrERCJORAJ4uOqqiuBCyjqGJMnBWIy8xlOeZ/wCggYTt
Saas407pZa3Xpb9joJcxEts=
=kX7O
-END PGP SIGNATURE-
