Ok, since my meeting got pushed I decided to get the new usage command
in my local copy to abuse it for a while. I did
C:...> fossil update tip
which (probably by blind luck) picked up the latest change [e11bec] to
the update-command branch. I then had to remember whether I last built
with MingW via CMD.EXE, via MSys bash, or from VS2010. I opened a VS2010
command prompt in my workspace, then did
C:...> cd win; nmake /f Makefile.msc
which churned as usual, then turned up an error in the SQLite amalgamation:
..\src\sqlite3.c(108355) : error C2275: 'tRowcnt' : illegal use of this type as
an expression
..\src\sqlite3.c(8274) : see declaration of 'tRowcnt'
..\src\sqlite3.c(108355) : error C2146: syntax error : missing ';' before
identifier 'iLower'
..\src\sqlite3.c(108355) : error C2065: 'iLower' : undeclared identifier
..\src\sqlite3.c(108356) : error C2275: 'tRowcnt' : illegal use of this type as
an expression
..\src\sqlite3.c(8274) : see declaration of 'tRowcnt'
..\src\sqlite3.c(108356) : error C2146: syntax error : missing ';' before
identifier 'iUpper'
That isn't my elephant at the moment, but surely someone wants to know.
The build instructions for Windows might have suffered from a touch of
bitrot as well... and in any case I always want JSON enabled and I want
a working build sooner than it will take to figure out why SQLite and
VS2010 are having a tiff. So I turned to MinGW32.
C:...> make -f win\Makefile.mingw
mkdir -p wbld
gcc -o wbld/translate src/translate.c
wbld/translate src/add.c >wbld/add_.c
'wbld' is not recognized as an internal or external command,
operable program or batch file.
make: *** [wbld/add_.c] Error 1
Oops, clearly the MinGW makefile is assuming bash or a similar shell is
the command processor. So after one more fossil clean --force, we try
bash under MSys...
$ make -f win/Makefile.mingw
....
$ ./fossil help --all
has the new "usage", but no "json". Oh yes, I forgot about
configuration. So once more, fossil clean --force, with the intent to do
./configure && make:
$ fossil clean --force
$ ./configure
.... problem with ZLib
which leads to a long garden path of build pain and annoyance starting
with building zlib itself, then the realization that it next wants
OpenSSL, and that I really don't want to go down this path. While it
would probably be a good idea to make ./configure better handle bash
running from the MSys environment, that also isn't my elephant for
today. So, back to the pre-configured Makefile.mingw, and the
recollection that it supported a conditional for enabling JSON:
$ fossil clean --force
$ make -f win/Makefile.mingw FOSSIL_ENABLE_JSON=1
....
$ ./fossil version
This is fossil version 1.26 [e11bec70ef] 2013-09-03 20:15:25 UTC
$ ./fossil help --all
3-way-merge close import redo tarball
add co info remote-url ticket
addremove commit init rename timeline
all configuration json revert ui
annotate dbstat leaves rm undo
artifact deconstruct ls scrub unset
bisect delete md5sum search update
branch descendants merge server usage
cat diff mv settings user
cgi export new sha1sum version
changes extras open sqlite3 whatis
checkout finfo pull stash wiki
ci gdiff push status winsrv
clean help rebuild sync zip
clone http reconstruct tag
$
$ fossil usage
CLI command usage history for this checkout:
Count Command
2 status
2 usage
1 clean
1 update
So far, so good, aside from the rocky garden path to remembering how I
usually build it here. I'll make this my usual fossil.exe and use it for
a while.
On 9/3/2013 2:26 PM, Stephan Beal wrote:
i don't think so. i i think maybe the recent "PGP Signed" timeline bits
(which i subsequently threw out) got done faster. And i'm certain i've
seen other devs do similar things in the past. You just happened to
suggest something that was easy to do and was helpful to me :). May you
continue to have such luck in your feature ideas.
I've certainly seen problems handled and fixes pushed to trunk in
remarkably short times. A whole new command, though...
There's no rush. We're about to (this week?) do the 1.27 release and i
probably won't trunk this until after that.
In your shoes I'd be torn between having the stats available from as
broad a user base as possible, and not pushing a brand new possibly
unstable feature into the wild in a rush. Its your call, obviously, but
I suspect I'd lean towards verify its safety, then trunk it sooner. But
then I always like to have stats to argue from....
--
Ross Berteig [email protected]
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
+1 626 351 1590 FAX
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
