Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-07-09 Thread Richard Hipp 
On Wed, Jul 6, 2011 at 5:30 PM, Eric e...@deptj.eu wrote:


 On Wed, July 6, 2011 6:11 am, Steve Bennett wrote:
  Hi Richard,
 
  I really dislike autoconf - a feeling cultivated through years of
  experience
  trying to use it.  And I think I'm probably not alone in that feeling.
 
  You are very much not alone. See
 http://msteveb.github.com/autosetup/why/
 

 Not wishing to rain on anyone's parade, but, as it says in the autoconf
 info page,

 Those who do not understand Autoconf are condemned to reinvent it,
 poorly. 


I rather like Steve's reimplementation.  It uses TCL.  But for systems that
do not have TCL installed by default, it includes the complete source code
for JimTcl which it automatically compiles and runs.  Unlike autoconf, I'm
actual able to follow the code for Steve's autosetup.

My only complaint with autosetup is that autosetup itself is maintained on
github :-(

The autosetup version of Fossil is now available on a branch.  Some
additional work is needed.

http://www.fossil-scm.org/fossil/timeline?r=autosetup



 Maybe not, but your first reference from the above page is a bit OTT (as
 some of the comments below it say).

 Regards,

 Eric

 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-07-09 Thread Matt Welland 
Worked great for me on two Ubuntu machines. One mildly unusual thing, make
install uses mv to put the binary in /usr/local/bin. Normally I think
autoconf generated Makefiles will use install or a sh script to emulated
install and keeps the executable in the build dir. Probably no big deal but
why deviate from what is familiar?

Matt
-=-

On Sat, Jul 9, 2011 at 1:28 PM, Richard Hipp d...@sqlite.org wrote:

 On Wed, Jul 6, 2011 at 5:30 PM, Eric e...@deptj.eu wrote:


 On Wed, July 6, 2011 6:11 am, Steve Bennett wrote:
  Hi Richard,
 
  I really dislike autoconf - a feeling cultivated through years of
  experience
  trying to use it.  And I think I'm probably not alone in that feeling.
 
  You are very much not alone. See
 http://msteveb.github.com/autosetup/why/
 

 Not wishing to rain on anyone's parade, but, as it says in the autoconf
 info page,

 Those who do not understand Autoconf are condemned to reinvent it,
 poorly. 


 I rather like Steve's reimplementation.  It uses TCL.  But for systems that
 do not have TCL installed by default, it includes the complete source code
 for JimTcl which it automatically compiles and runs.  Unlike autoconf, I'm
 actual able to follow the code for Steve's autosetup.

 My only complaint with autosetup is that autosetup itself is maintained on
 github :-(

 The autosetup version of Fossil is now available on a branch.  Some
 additional work is needed.

 http://www.fossil-scm.org/fossil/timeline?r=autosetup



 Maybe not, but your first reference from the above page is a bit OTT (as
 some of the comments below it say).

 Regards,

 Eric

 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




 --
 D. Richard Hipp
 d...@sqlite.org

 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-07-09 Thread Steve Bennett 
On 10/07/2011, at 6:28 AM, Richard Hipp wrote:On Wed, Jul 6, 2011 at 5:30 PM, Eric e...@deptj.eu wrote:


On Wed, July 6, 2011 6:11 am, Steve Bennett wrote:
 Hi Richard,

 I really dislike autoconf - a feeling cultivated through years of
 experience
 trying to use it. And I think I'm probably not alone in that feeling.

 You are very much not alone. See http://msteveb.github.com/autosetup/why/


Not wishing to rain on anyone's parade, but, as it says in the autoconf
info page,

"Those who do not understand Autoconf are condemned to reinvent it,
poorly. "I rather like Steve's reimplementation. It uses TCL. But for systems that do not have TCL installed by default, it includes the complete source code for JimTcl which it automatically compiles and runs. Unlike autoconf, I'm actual able to follow the code for Steve's autosetup.

My only complaint with autosetup is that autosetup itself is maintained on github :-(The autosetup version of Fossil is now available on a branch. Some additional work is needed. http://www.fossil-scm.org/fossil/timeline?r=autosetupGreat. Bug reports and requests are welcome.I did notice one small bug in that version. See fix attached.Cheers,Steve
--µWeb: Embedded Web Framework - http://uweb.workware.net.au/WorkWare Systems Pty LtdW: www.workware.net.au   P: +61 434 921 300E: ste...@workware.net.au F: +61 7 3391 6002



fix-autoconfig.patch
Description: Binary data
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-07-09 Thread Steve Bennett 
On 10/07/2011, at 7:26 AM, Matt Welland wrote:

 Worked great for me on two Ubuntu machines. One mildly unusual thing, make 
 install uses mv to put the binary in /usr/local/bin. Normally I think 
 autoconf generated Makefiles will use install or a sh script to emulated 
 install and keeps the executable in the build dir. Probably no big deal but 
 why deviate from what is familiar?

That's the way it worked previously.
I tried to be as unobtrusive as possible with the initial version.

Cheers,
Steve

 
 Matt
 -=-
 
 On Sat, Jul 9, 2011 at 1:28 PM, Richard Hipp d...@sqlite.org wrote:
 On Wed, Jul 6, 2011 at 5:30 PM, Eric e...@deptj.eu wrote:
 
 On Wed, July 6, 2011 6:11 am, Steve Bennett wrote:
  Hi Richard,
 
  I really dislike autoconf - a feeling cultivated through years of
  experience
  trying to use it.  And I think I'm probably not alone in that feeling.
 
  You are very much not alone. See http://msteveb.github.com/autosetup/why/
 
 
 Not wishing to rain on anyone's parade, but, as it says in the autoconf
 info page,
 
 Those who do not understand Autoconf are condemned to reinvent it,
 poorly. 
 
 I rather like Steve's reimplementation.  It uses TCL.  But for systems that 
 do not have TCL installed by default, it includes the complete source code 
 for JimTcl which it automatically compiles and runs.  Unlike autoconf, I'm 
 actual able to follow the code for Steve's autosetup.
 
 My only complaint with autosetup is that autosetup itself is maintained on 
 github :-(
 
 The autosetup version of Fossil is now available on a branch.  Some 
 additional work is needed.
 
 http://www.fossil-scm.org/fossil/timeline?r=autosetup
  
 
 Maybe not, but your first reference from the above page is a bit OTT (as
 some of the comments below it say).
 
 Regards,
 
 Eric
 
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
 
 
 
 -- 
 D. Richard Hipp
 d...@sqlite.org
 
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
 
 
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

--
µWeb: Embedded Web Framework - http://uweb.workware.net.au/
WorkWare Systems Pty Ltd
W: www.workware.net.au  P: +61 434 921 300
E: ste...@workware.net.au   F: +61 7 3391 6002





___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-07-07 Thread Steve Bennett 
On 07/07/2011, at 2:22 PM, Matt Welland wrote:

 As an end user this appears to the best alternative I've seen so far. The 
 fact that autosetup presents a familiar ./configure  make interface is 
 fantastic - if it really works as advertised. 
 
 Does the cross compilation really work? I'd really like to put fossil on my 
 n900 but I don't want to set up scratchbox (again) right now.
 
 Matt
 -=-


$ ./configure --host=mips-unknown-nto-qnx6.5.0
Host System...mips-unknown-nto-qnx6.5.0
Build System...i686-pc-linux-gnu
C compiler...ccache mips-unknown-nto-qnx6.5.0-gcc -g -O2
C++ compiler...ccache mips-unknown-nto-qnx6.5.0-c++ -g -O2
Checking for stdlib.h...ok
Checking for stdint.h...ok
Checking for inttypes.h...ok
Checking for uint32_t...ok
Checking for uint16_t...ok
Checking for int16_t...ok
Checking for uint8_t...ok
Checking for pread...ok
Checking for tclsh...ok
Checking for zlib.h...ok
Checking libs for inflateEnd...-lz
Checking for ssl via pkg-config...ok
HTTP support enabled
Checking for stdio.h...ok
Checking for readline/readline.h...not found
Checking for editline/readline.h...not found
Checking libs for gethostbyname...no
Checking libs for socket...-lsocket
Checking for getpassphrase...not found
Checking libs for getpass...none needed
Created Makefile from Makefile.in
autoconfig.h is unchanged
$ make
cc -o ./bld/translate ./src/translate.c
./bld/translate ./src/add.c ./bld/add_.c
./bld/translate ./src/allrepo.c ./bld/allrepo_.c
./bld/translate ./src/attach.c ./bld/attach_.c
./bld/translate ./src/bag.c ./bld/bag_.c
...snip...
./bld/translate ./src/zip.c ./bld/zip_.c
cc -o ./bld/mkindex ./src/mkindex.c
./bld/mkindex ./bld/add_.c ./bld/allrepo_.c ./bld/attach_.c ./bld/bag_.c 
./bld/bisect_.c ./bld/blob_.c ./bld/branch_.c ./bld/browse_.c ./bld/captcha_.c 
./bld/cgi_.c ./bld/checkin_.c ./bld/checkout_.c ./bld/clearsign_.c 
./bld/clone_.c ./bld/comformat_.c ./bld/configure_.c ./bld/content_.c 
./bld/db_.c ./bld/delta_.c ./bld/deltacmd_.c ./bld/descendants_.c ./bld/diff_.c 
./bld/diffcmd_.c ./bld/doc_.c ./bld/encode_.c ./bld/event_.c ./bld/export_.c 
./bld/file_.c ./bld/finfo_.c ./bld/glob_.c ./bld/graph_.c ./bld/gzip_.c 
./bld/http_.c ./bld/http_socket_.c ./bld/http_ssl_.c ./bld/http_transport_.c 
./bld/import_.c ./bld/info_.c ./bld/leaf_.c ./bld/login_.c ./bld/main_.c 
./bld/manifest_.c ./bld/md5_.c ./bld/merge_.c ./bld/merge3_.c ./bld/name_.c 
./bld/path_.c ./bld/pivot_.c ./bld/popen_.c ./bld/pqueue_.c ./bld/printf_.c 
./bld/rebuild_.c ./bld/report_.c ./bld/rss_.c ./bld/schema_.c ./bld/search_.c 
./bld/setup_.c ./bld/sha1_.c ./bld/shun_.c ./bld/skins_.c ./bld/sqlcmd_.c 
./bld/stash_.c ./bld/stat_.c ./bld/style_.c ./bld/sync_.c ./bld/tag_.c 
./bld/tar_.c ./bld/th_main_.c ./bld/timeline_.c ./bld/tkt_.c ./bld/tktsetup_.c 
./bld/undo_.c ./bld/update_.c ./bld/url_.c ./bld/user_.c ./bld/verify_.c 
./bld/vfile_.c ./bld/wiki_.c ./bld/wikiformat_.c ./bld/winhttp_.c ./bld/xfer_.c 
./bld/zip_.c bld/page_index.h
cc -o ./bld/makeheaders ./src/makeheaders.c
awk '{ printf #define MANIFEST_UUID \%s\\n, $1}'  ./src/../manifest.uuid 
./bld/VERSION.h
awk '{ printf #define MANIFEST_VERSION \[%.10s]\\n, $1}'  
./src/../manifest.uuid ./bld/VERSION.h
awk '$1==D{printf #define MANIFEST_DATE \%s %s\\n, 
substr($2,1,10),substr($2,12,8)}'  ./src/../manifest ./bld/VERSION.h
./bld/makeheaders  ./bld/add_.c:./bld/add.h ./bld/allrepo_.c:./bld/allrepo.h 
./bld/attach_.c:./bld/attach.h ./bld/bag_.c:./bld/bag.h 
./bld/bisect_.c:./bld/bisect.h ./bld/blob_.c:./bld/blob.h 
./bld/branch_.c:./bld/branch.h ./bld/browse_.c:./bld/browse.h 
./bld/captcha_.c:./bld/captcha.h ./bld/cgi_.c:./bld/cgi.h 
./bld/checkin_.c:./bld/checkin.h ./bld/checkout_.c:./bld/checkout.h 
./bld/clearsign_.c:./bld/clearsign.h ./bld/clone_.c:./bld/clone.h 
./bld/comformat_.c:./bld/comformat.h ./bld/configure_.c:./bld/configure.h 
./bld/content_.c:./bld/content.h ./bld/db_.c:./bld/db.h 
./bld/delta_.c:./bld/delta.h ./bld/deltacmd_.c:./bld/deltacmd.h 
./bld/descendants_.c:./bld/descendants.h ./bld/diff_.c:./bld/diff.h 
./bld/diffcmd_.c:./bld/diffcmd.h ./bld/doc_.c:./bld/doc.h 
./bld/encode_.c:./bld/encode.h ./bld/event_.c:./bld/event.h 
./bld/export_.c:./bld/export.h ./bld/file_.c:./bld/file.h 
./bld/finfo_.c:./bld/finfo.h ./bld/glob_.c:./bld/glob.h 
./bld/graph_.c:./bld/graph.h ./bld/gzip_.c:./bld/gzip.h 
./bld/http_.c:./bld/http.h ./bld/http_socket_.c:./bld/http_socket.h 
./bld/http_ssl_.c:./bld/http_ssl.h 
./bld/http_transport_.c:./bld/http_transport.h ./bld/import_.c:./bld/import.h 
./bld/info_.c:./bld/info.h ./bld/leaf_.c:./bld/leaf.h 
./bld/login_.c:./bld/login.h ./bld/main_.c:./bld/main.h 
./bld/manifest_.c:./bld/manifest.h ./bld/md5_.c:./bld/md5.h 
./bld/merge_.c:./bld/merge.h ./bld/merge3_.c:./bld/merge3.h 
./bld/name_.c:./bld/name.h ./bld/path_.c:./bld/path.h 
./bld/pivot_.c:./bld/pivot.h ./bld/popen_.c:./bld/popen.h 
./bld/pqueue_.c:./bld/pqueue.h ./bld/printf_.c:./bld/printf.h 
./bld/rebuild_.c:./bld/rebuild.h ./bld/report_.c:./bld/report.h

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-07-07 Thread Steve Landers 

On 07/07/2011, at 3:03 PM, Stephan Beal wrote:

 On Thu, Jul 7, 2011 at 8:31 AM, Steve Bennett ste...@workware.net.au wrote:
 On 07/07/2011, at 2:22 PM, Matt Welland wrote:
 Does the cross compilation really work?
 
 ... 
 $ ./configure --host=mips-unknown-nto-qnx6.5.0
 Host System...mips-unknown-nto-qnx6.5.0
 ...
 $ file fossil
 fossil: ELF 32-bit MSB executable, MIPS, MIPS-II version 1, dynamically 
 linked (uses shared libs), with unknown capability 0x4100 = 0xf676e75, 
 not stripped
 
 i'm convinced :). That would certainly greatly simplify the release of the 
 pre-built fossil binaries.
 
 i spent about half an hour reading through autosetup's docs last night and i 
 will certainly be trying it out on a tree or three of mine. i don't know tcl, 
 but a tool like this one provides a good motivator for learning it.

It's actually quite simple if you forget formal grammars and think command arg 
arg arg .   Simple but not simplistic,  you get sophisticated features 
like event driven I/O, threads (if you want them, but mostly you don't need 
to), co-routines,  full I18N and localization, single file deployment via 
starkits, etc.

And there's plenty of Tcler's on this list who will help you :)

A good place to start is the Tclers Wiki at http://wiki.tcl.tk ... perhaps 
starting at http://wiki.tcl.tk/20789

Steve___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-07-07 Thread Bill Burdick 
Has anyone looked at cmake?  A lot of projects have switched from autoconf
to cmake (MySQL, KDE, Blender, Wireshark, ...).

Bill

On Thu, Jul 7, 2011 at 4:15 AM, paolo lulli plu...@gmail.com wrote:

 What about a try with 'autoproject' to give a start ?

 Regards,
 P.

 --
 www.lulli.net

 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-07-07 Thread Remigiusz Modrzejewski 

On Jul 7, 2011, at 20:08 , Bill Burdick wrote:

 Has anyone looked at cmake?  A lot of projects have switched from autoconf
 to cmake (MySQL, KDE, Blender, Wireshark, ...).

Read the thread to see why cmake was already rejected.


Kind regards,
Remigiusz Modrzejewski



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-07-06 Thread Eric 

On Wed, July 6, 2011 6:11 am, Steve Bennett wrote:
 Hi Richard,

 I really dislike autoconf - a feeling cultivated through years of
 experience
 trying to use it.  And I think I'm probably not alone in that feeling.

 You are very much not alone. See http://msteveb.github.com/autosetup/why/


Not wishing to rain on anyone's parade, but, as it says in the autoconf
info page,

Those who do not understand Autoconf are condemned to reinvent it,
poorly. 

Maybe not, but your first reference from the above page is a bit OTT (as
some of the comments below it say).

Regards,

Eric

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-07-06 Thread Steve Bennett 
On 07/07/2011, at 7:30 AM, Eric wrote:

 
 On Wed, July 6, 2011 6:11 am, Steve Bennett wrote:
 Hi Richard,
 
 I really dislike autoconf - a feeling cultivated through years of
 experience
 trying to use it.  And I think I'm probably not alone in that feeling.
 
 You are very much not alone. See http://msteveb.github.com/autosetup/why/
 
 
 Not wishing to rain on anyone's parade, but, as it says in the autoconf
 info page,
 
 Those who do not understand Autoconf are condemned to reinvent it,
 poorly. 

All this says is this is a complex problem and you can never solve it
better than the way we solved it.

This is not conducive to progress.
In building autosetup, I've learnt more about autoconf than I ever wanted
to know :-)

 
 Maybe not, but your first reference from the above page is a bit OTT (as
 some of the comments below it say).

Indeed. And just complaining about something without offering an alternative
doesn't help much. autoconf isn't terrible, but it can be a frustrating 
experience.

Cheers,
Steve

--
µWeb: Embedded Web Framework - http://uweb.workware.net.au/
WorkWare Systems Pty Ltd
W: www.workware.net.au  P: +61 434 921 300
E: ste...@workware.net.au   F: +61 7 3391 6002





___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-07-06 Thread Matt Welland 
As an end user this appears to the best alternative I've seen so far. The
fact that autosetup presents a familiar ./configure  make interface is
fantastic - if it really works as advertised.

Does the cross compilation really work? I'd really like to put fossil on my
n900 but I don't want to set up scratchbox (again) right now.

Matt
-=-

On Wed, Jul 6, 2011 at 3:31 PM, Steve Bennett ste...@workware.net.auwrote:

 On 07/07/2011, at 7:30 AM, Eric wrote:

 
  On Wed, July 6, 2011 6:11 am, Steve Bennett wrote:
  Hi Richard,
 
  I really dislike autoconf - a feeling cultivated through years of
  experience
  trying to use it.  And I think I'm probably not alone in that feeling.
 
  You are very much not alone. See
 http://msteveb.github.com/autosetup/why/
 
 
  Not wishing to rain on anyone's parade, but, as it says in the autoconf
  info page,
 
  Those who do not understand Autoconf are condemned to reinvent it,
  poorly. 

 All this says is this is a complex problem and you can never solve it
 better than the way we solved it.

 This is not conducive to progress.
 In building autosetup, I've learnt more about autoconf than I ever wanted
 to know :-)

 
  Maybe not, but your first reference from the above page is a bit OTT (as
  some of the comments below it say).

 Indeed. And just complaining about something without offering an
 alternative
 doesn't help much. autoconf isn't terrible, but it can be a frustrating
 experience.

 Cheers,
 Steve

 --
 µWeb: Embedded Web Framework - http://uweb.workware.net.au/
 WorkWare Systems Pty Ltd
 W: www.workware.net.au  P: +61 434 921 300
 E: ste...@workware.net.au   F: +61 7 3391 6002





 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-07-05 Thread Steve Bennett 
Hi Richard,

 I really dislike autoconf - a feeling cultivated through years of experience
 trying to use it.  And I think I'm probably not alone in that feeling.

You are very much not alone. See http://msteveb.github.com/autosetup/why/

  I've
 tried to avoid having to use autoconf in Fossil and have been reasonably
 successful at that for the first 5 years.  But I think we may be nearing the
 point where going to autoconf is inevitable.  (sigh...)

Certainly something is needed.

 
 So, I'm asking for volunteers for people with better autoconf-foo than me,
 to put together an autoconf/automake setup for Fossil.  If you are good with
 autoconf/automake, please consider contributing your expertise to the
 project.

autosetup is designed to be transparently compatible with autoconf for end 
users.
It is written in Tcl, but does not require Tcl to be installed since it will 
(automatically)
build a bootstrap version of the Jim Tcl interpreter if another Tcl interpreter 
is not found.
Only a C compiler is required.

Attached is a patch against the latest fossil trunk which adds autosetup 
support.

 
 Objectives (not an any particular order):
 
 (1) ./configure; make install should work on all unix systems

Done.

 
 (2) There should be a default Makefile that does not require configure
 that will work on most common systems simply by running make.

Yes. Makefile is left in place. configure creates GNUmakefile which takes 
precedence.

 
 (3) The result should fix tickets
 
 http://www.fossil-scm.org/fossil/info/084eedc010
  and
 
 http://www.fossil-scm.org/fossil/info/5ad1d9a23c

Both of those should be addressed, but we need a Haiku tester.

 
 
 (4) The result should have a 0 Fail-Score according to
 
 https://www.theopensourceway.org/wiki/How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL

I will leave others to judge this.

 
 
 (5) Further to (4) above, there needs to be a configuration option that
 causes the result to link against a system SQLite library rather than using
 the built-in SQLite library.

  --disable-internal-sqlite  Don't use the internal sqlite, use the system 
one

 
 (6) There should be a configure option to enable static linking, in order to
 simplify the generation of binaries for use inside chroot jails.

  --static   Link a static executable

But probably won't work on any platform except Linux, and even there glibc
doesn't not like to be statically linked :-(

 
 (7) There should be a configure option to enable and disable SSL support.

  --with-openssl=path|auto|none  Look for openssl in the given path, or auto or 
none

 
 (8) There should be a configure option to enable and disable command-line
 editing support for the fossil sql command.

  --disable-lineedit Disable line editing

Actually, previously line editing was always disabled.

 
 (9) There should be a configure option to enable FOSSIL_DEBUG.

  --fossil-debug Build with fossil debugging enabled

 
 (10) The src/makemake.tcl script should continue to work - it should still
 build out the various windows makefiles and the unix main.mk file.  In
 other words, autoconf should make use of main.mk.

Yes. Only minor modifications required.

 
 (11) Bonus points if you can get a configure script that can be used to
 cross-compile Fossil from one unix platform to another, and double bonus
 points if you can get a configure script that will cross-compile Fossil on
 Linux targeting windows!

Yes. With --host I have cross compiled Mac OS X - arm-linux,
x86-linux - qnx-mips, x86-linux - mingw32 as well as native builds
on Mac OS X, cygwin and x86-linux.

 
 If you are willing to help with this, your contribution will be greatly
 appreciated.  Tnx.

In addition to the attached patch, autosetup needs to be installed in the 
project.
(It is bundled with the project in order to avoid any dependencies)

The easiest way is to fetch it via git or a tar/zip download at: 
https://github.com/msteveb/autosetup

And then from the fossil source directory, run: autosetup-location/autosetup 
--install
Alternatively I can provide a patch which does this.

Feedback is welcome.
There are a number of improvements which could be made (.e.g. for installation)
which would require more changes to the current makemake.tcl

Cheers,
Steve

--
µWeb: Embedded Web Framework - http://uweb.workware.net.au/
WorkWare Systems Pty Ltd
W: www.workware.net.au  P: +61 434 921 300
E: ste...@workware.net.au   F: +61 7 3391 6002






0002-Add-autosetup-support-to-configure-the-build.patch
Description: Binary data
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-16 Thread Michael Richter 
On 14 June 2011 15:57, Stephan Beal sgb...@googlemail.com wrote:

 On Tue, Jun 14, 2011 at 1:27 AM, Richard Hipp d...@sqlite.org wrote:

 If you have a way other than autoconf to generate a universal build script
 that runs on any unix machine without special software installed, then that
 will be fine.  CMake does not qualify because it is not installed by default
 on most unix boxes.  I think autoconf is probably going to be the only
 general-purpose solution, but I am open to alternatives if you have them.


 /bin/sh

 it's not nearly as painful as the Auto, my ass! Tools.


Mix that with /usr/bin/awk or it will be as painful as the
auto-my-ass-tools.  Luckily Awk is mandated by POSIX so it's guaranteed to
be on any POSIX-compliant system.

-- 
Perhaps people don't believe this, but throughout all of the discussions of
entering China our focus has really been what's best for the Chinese people.
It's not been about our revenue or profit or whatnot.
--Sergey Brin, demonstrating the emptiness of the don't be evil mantra.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-16 Thread Michael Richter 
*A Modest Proposal*
*
*
The problems with the auto* tools are myriad and well-documented in the grey
hairs and bald pates of many a poor soul who's had to put them to use.
 Other environments suggested -- CMake, QMake, Jam, et al -- suffer from
assorted platform problems including (but not limited to):

   1. Not being ported to many potential target platforms (QNX, for
   example).
   2. Supporting some platforms better than others.
   3. Requiring huge resources to get working.

One option -- using a Bourne shell script (perhaps augmented with Awk) --
works well on POSIX-compliant systems but, again, leaves Windows users in
the lurch for no particularly good reason.  (Yes, I know of Cygwin -- and
wouldn't wish it on my worst enemy.  I also know of MinGW/MSYS, but this is
a suboptimal solution for people who don't *want* to Unixify their boxen.)

So...

My proposal is to put all platforms on an even footing.  Generate the
Makefiles using a SNOBOL4 http://www.snobol4.org/ program.  SNOBOL4 isn't
native to *any* platform any longer, but there is a SNOBOL4 implementation
available for a whole lot of systems http://www.snobol4.org/csnobol4/curr/,
and there are very few languages (read: none) that have SNOBOL4's raw power
for text manipulation.

Of course SNOBOL4 isn't on every platform by default, but that, too, is OK.
 The tarball for that SNOBOL4 system is under 3MB uncompressed (under ¾MB
compressed) so we could just include a full SNOBOL4 implementation in Fossil
itself and build it (ironically it uses auto*) as part of the building of
Fossil.

I mean yeah, sure, SNOBOL4 has a pretty funky and odd syntax, but it's far
less painful than auto*
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-16 Thread Thomas Schnurrenberger 

On 16.06.2011 14:32, Richard Hipp wrote:

On Mon, Jun 13, 2011 at 7:07 PM, Steve Havelkasmh...@gmail.com  wrote:


Is it necessary that it's autoconf?  Or would you take a CMake-based build
script?




Though I think autoconf is also necessary (for use by people who do not have
cmake installed) I will also consider having appropriate cmake scripts in
the tree, for use by people have and prefer cmake.  Would anybody care to
contribute the appropriate files?



Attached is my experiment of building Fossil with CMake. I was able to
successfully generate a makefile for MinGW on Windows and for a Linux
distribution based on Debian.
Place the CMakeLists.txt file in the top directory of the Fossil 
development tree.


On Windows, the makeheaders program needs a small patch because the
generated makefile uses the -f option and there was a problem with full
pathnames which include a colon in the device name.

--
tsbg
PROJECT(Fossil C)

CMAKE_MINIMUM_REQUIRED(VERSION 2.8)

# Build options.
OPTION(FOSSIL_BUILD_STATIC Build Fossil static TRUE)
OPTION(FOSSIL_ENABLE_SSL Enable SSL support FALSE)

# Include some macros.
INCLUDE(CheckIncludeFile)

# Source files which gets processed by the translate program.
SET(TRANS_SRCS
  add allrepo attach bag bisect blob branch browse captcha cgi checkin
  checkout clearsign clone comformat configure content db delta deltacmd
  descendants diff diffcmd doc encode event export file finfo glob graph gzip
  http http_socket http_transport import info leaf login main manifest md5
  merge merge3 name path pivot popen pqueue printf rebuild report rss schema
  search setup sha1 shun skins sqlcmd stash stat style sync tag tar th_main
  timeline tkt tktsetup undo update url user verify vfile wiki wikiformat
  winhttp xfer zip http_ssl
)

# Additional source files.
SET(OTHER_SRCS
  src/sqlite3.c src/shell.c src/th.c src/th_lang.c
)

# Add the resource file on windows to the source files.
IF(WIN32)
  SET(OTHER_SRCS ${OTHER_SRCS} win/fossil.rc)
ENDIF(WIN32)

# Set compile definitions for src/shell.c.
SET(SHELL_COMP_DEFS
  main=sqlite3_shell
  SQLITE_OMIT_LOAD_EXTENSION=1
)
SET_SOURCE_FILES_PROPERTIES(src/shell.c
  PROPERTIES COMPILE_DEFINITIONS ${SHELL_COMP_DEFS}
)

# Set compile definitions for src/sqlite.c.
SET(SQLITE3_COMP_DEFS
  SQLITE_OMIT_LOAD_EXTENSION=1
  SQLITE_THREADSAFE=0
  SQLITE_DEFAULT_FILE_FORMAT=4
  SQLITE_ENABLE_STAT2
  SQLITE_ENABLE_LOCKING_STYLE=0
  localtime=fossil_localtime
)
SET_SOURCE_FILES_PROPERTIES(src/sqlite3.c
  PROPERTIES COMPILE_DEFINITIONS ${SQLITE3_COMP_DEFS}
)

# Build the makeheaders program.
ADD_EXECUTABLE(makeheaders src/makeheaders.c)
GET_TARGET_PROPERTY(MAKEHEADERS_LOC makeheaders LOCATION)

# Build the translate program.
ADD_EXECUTABLE(translate src/translate.c)
GET_TARGET_PROPERTY(TRANSLATE_LOC translate LOCATION)

# Build the mkindex program.
ADD_EXECUTABLE(mkindex src/mkindex.c)
GET_TARGET_PROPERTY(MKINDEX_LOC mkindex LOCATION)

# Build the version program.
ADD_EXECUTABLE(version win/version.c)
GET_TARGET_PROPERTY(VERSION_LOC version LOCATION)

# Custom command to build the VERSION.h include file.
ADD_CUSTOM_COMMAND(
  OUTPUT  ${PROJECT_BINARY_DIR}/VERSION.h
  DEPENDS version
  ${PROJECT_SOURCE_DIR}/manifest.uuid
  ${PROJECT_SOURCE_DIR}/manifest
  COMMAND ${VERSION_LOC}
  ARGS${PROJECT_SOURCE_DIR}/manifest.uuid
  ${PROJECT_SOURCE_DIR}/manifest
 ${PROJECT_BINARY_DIR}/VERSION.h
  COMMENT Generating VERSION.h ...
)

# Custom commands to build the translated sources.
FOREACH(SRC ${TRANS_SRCS})

  ADD_CUSTOM_COMMAND(
OUTPUT  ${PROJECT_BINARY_DIR}/${SRC}_.c
DEPENDS translate
${PROJECT_SOURCE_DIR}/src/${SRC}.c
COMMAND ${TRANSLATE_LOC}
ARGS${PROJECT_SOURCE_DIR}/src/${SRC}.c
   ${PROJECT_BINARY_DIR}/${SRC}_.c
COMMENT Translating src/${SRC}.c ...
  )

  # Build a list of all the results.
  SET(TRANS_SRC ${TRANS_SRC} ${PROJECT_BINARY_DIR}/${SRC}_.c)

ENDFOREACH(SRC)

# Custom command to build page_index.h.
ADD_CUSTOM_COMMAND(
  OUTPUT  ${PROJECT_BINARY_DIR}/page_index.h
  DEPENDS mkindex
  ${TRANS_SRC}
  COMMAND ${MKINDEX_LOC}
  ARGS${TRANS_SRC}
 ${PROJECT_BINARY_DIR}/page_index.h
  COMMENT Generating page_index.h ...
)
ADD_CUSTOM_TARGET(page_index DEPENDS ${PROJECT_BINARY_DIR}/page_index.h)

# Create an input file for the makeheaders program.
FILE(WRITE ${PROJECT_BINARY_DIR}/mkhdr.dat
# Warning: this file is automatically generated by CMake.
${PROJECT_SOURCE_DIR}/src/sqlite3.h
${PROJECT_SOURCE_DIR}/src/th.h
${PROJECT_BINARY_DIR}/VERSION.h\n
)
FOREACH(SRC ${TRANS_SRCS})
  FILE(APPEND ${PROJECT_BINARY_DIR}/mkhdr.dat
${PROJECT_BINARY_DIR}/${SRC}_.c:${PROJECT_BINARY_DIR}/${SRC}.h\n
  )
  # Build a list of all the generated header files.
  SET(GEN_HDRS ${GEN_HDRS} ${PROJECT_BINARY_DIR}/${SRC}.h)
ENDFOREACH(SRC)

# Custom commands to build the header files.
ADD_CUSTOM_COMMAND(
  OUTPUT  ${PROJECT_BINARY_DIR}/headers ${GEN_HDRS}
  DEPENDS makeheaders

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-16 Thread Altu Faltu 
Will the move to autoconf remove ability to build fossil for Windows through 
MinGW and will make us install MSVC?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-16 Thread Richard Hipp 
On Thu, Jun 16, 2011 at 10:33 PM, Altu Faltu altufa...@mail.com wrote:

  Will the move to autoconf remove ability to build fossil for Windows
 through MinGW and will make us install MSVC?


No.  Those capabilities are retained. There will be separate makefiles for
windows.  autoconf is used on unix only.  (Maybe MinGW too, but that is not
a requirement.)




 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-16 Thread Altu Faltu 
Oh. Good to know. But then are there chances of makefile and autoconf not 
staying in sync... I request MinGW too be part of requirement.

- Original Message -
From: Richard Hipp
Sent: 06/17/11 08:07 AM
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] Needed: volunteer to autoconf Fossil


 On Thu, Jun 16, 2011 at 10:33 PM, Altu Faltu  altufa...@mail.com  wrote:
Will the move to autoconf remove ability to build fossil for Windows through 
MinGW and will make us install MSVC?

 No. Those capabilities are retained. There will be separate makefiles for 
windows. autoconf is used on unix only. (Maybe MinGW too, but that is not a 
requirement.)

 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org 
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users 



 --
 D. Richard Hipp
 d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-15 Thread Michal Suchanek 
On 15 June 2011 07:55, Matt Welland estifo...@gmail.com wrote:
 All of these alternative build systems are a PITA on one system or another.
 If it requires jam, cmake or anything that requires installing prerequisites
 9 times out of 10 I won't even try that software unless there is a binary
 install available somewhere or a pre-assembled Makefile.

 I thought that from an end user perspective all that is needed with autoconf
 is sh. The requirement is on the developer to run autoconf before making the
 tar. I thought autoconf itself is not needed on the platform where the build
 is being done, correct??

So long as you get all the tests right, yes.

However, in my experience most autotoolized projects require some
patches to random parts, and most often the auto* parts requiring the
auto* suite on the user's system.

For a long time building on OS X required regenerating the auto* parts
of pretty much everything because only fresh autotools supported it,
and scripts generated by older tools failed (and everybody used some
random old autotools). That's for an experience from slightly exotic
platform.

The alternatives usually require the configuration tool to be present
to generate *any* makefile skipping the intermediate shell script
step.

This seems like a drawback but consider that

 - in many cases when you have to build the tools in question you
would have to build autotools to regenerate the shell script anyway
 - the tools are available for most platforms anyway
 - cross-building is an option for overly uncooperative exotic platforms
 - not relying on the intermediate shell script makes maintenance and
dependency tracking easier

I would like to see, eg. platforms supported by autotools out of the
box that don't have CMake or Python.

Thanks

Michal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-15 Thread Twylite 
On 09:59 PM, Matt Welland wrote:
 For fossil you could keep the files generated by autoconf (not the 
 ./configure step but the initialization step) checked in. Then it is 
 just ./configure  make install on most systems. For anything weird 
 (e.g. windows) provide a Makefile.win32 or similar.
Right, so maintain multiple build systems because the one available 
out-of-the-box on your platform doesn't support one of the major target 
platforms.  In doing so, ensure that the Windows build files are never 
quite up to date, so that rather than contributing to the project 
Windows-based developers spend their time fixing build problems.

Twylite


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-15 Thread Michal Suchanek 
On 15 June 2011 09:47, Twylite twyl...@crypt.co.za wrote:
 On 09:59 PM, Matt Welland wrote:
 For fossil you could keep the files generated by autoconf (not the
 ./configure step but the initialization step) checked in. Then it is
 just ./configure  make install on most systems. For anything weird
 (e.g. windows) provide a Makefile.win32 or similar.
 Right, so maintain multiple build systems because the one available
 out-of-the-box on your platform doesn't support one of the major target
 platforms.  In doing so, ensure that the Windows build files are never
 quite up to date, so that rather than contributing to the project
 Windows-based developers spend their time fixing build problems.

Autotools can be installed and operated on Windows like most other
build configuration systems.

BTW Microsoft ships gcc for SFU with Windows 7.

Thanks

Michal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-15 Thread Michal Suchanek 
On 15 June 2011 08:37, Alexander Vladimirov id...@idkfa.org.ru wrote:
 how abouth this: http://buildconf.brlcad.org

A script like that is standard part of many autotoolized projects. In
fact, most people can't build an autotoolized project (other than
release tarballs with pre-generated configure that happens to work for
them) without such script present.

That does not alleviate the need to write autotools tests, keep up
with changing syntax/semantics between autotools version, etc.

Thanks

Michal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-15 Thread Arjen Markus 
Hello Graeme,

On 2011-06-15 11:04, Graeme Gill wrote:
 Michal Suchanek wrote:
 Autotools can be installed and operated on Windows like most other
 build configuration systems.
 
 I'm not sure that's possible without installing a UNIX like shell
 and set of tools. This is rather foreign for a native MSWin developer.
 

You're quite right - it requires something like winbash, MSYS or
Cygwin to be installed on the system. It is certainly not something
the typical Windows developer would have.

Regards,

Arjen
 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-15 Thread Joerg Sonnenberger 
On Mon, Jun 13, 2011 at 10:03:03AM -0400, Richard Hipp wrote:
 So, I'm asking for volunteers for people with better autoconf-foo than me,
 to put together an autoconf/automake setup for Fossil.  If you are good with
 autoconf/automake, please consider contributing your expertise to the
 project.

Basic support can be found on the autoconf branch. Two comments for
interested parties:

(1) You have run autoconf yourself for now, the generated script will be
checked in once everything has been stabilized somewhat.

(2) This is still the minimal version of support, e.g. the Makefile
still requires include support and doesn't follow many conventions for
variable names etc. I wanted to keep it non-intrusive for the first
change set.

 Objectives (not an any particular order):
 
 (1) ./configure; make install should work on all unix systems

The one candidate here that may or may not make problems is finding
zlib. At the moment it expects it in the compiler search path or adding
the normal LDFLAGS/CFLAGS/CPPFLAGS passing to configure. If someone has
a more exotic version that would really benefit from a --with-zlib
option to specify the path in a simpler way, I'm all ears.

OpenSSL detection uses the macro from the autoconf library, which tries
pkg-config first and falls back to more arcane guessing otherwise.

 (2) There should be a default Makefile that does not require configure
 that will work on most common systems simply by running make.

make -f Makefile.classic does this.

 
 (3) The result should fix tickets
 http://www.fossil-scm.org/fossil/info/084eedc010 and
 http://www.fossil-scm.org/fossil/info/5ad1d9a23c

I think the second is gone away. The former likes needs similar handling
to -lnsl and -lsocket on Solaris. Someone from Haiku-land to comment on
that?

 (4) The result should have a 0 Fail-Score according to
 https://www.theopensourceway.org/wiki/How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL

Strictly speaking, part of the build falls into the last point of
Building from source :) I'll do another round to add support for
HOST_CC / HOST_CFLAGS later, this is a semi-standard way to do this.

 (5) Further to (4) above, there needs to be a configuration option that
 causes the result to link against a system SQLite library rather than using
 the built-in SQLite library.

Will do. Are there versions requirement to validate here?

 (6) There should be a configure option to enable static linking, in order to
 simplify the generation of binaries for use inside chroot jails.

You can pass LDFLAGS=-static for this purpose, not sure if a separate
option for this really helps.

 (7) There should be a configure option to enable and disable SSL support.

Default checks the presence of OpenSSL and enables HTTPS support based
on that. If --enable-openssl is present, missing OpenSSL is fatal; if
--disable-openssl is present, the check will be skipped.

 (8) There should be a configure option to enable and disable command-line
 editing support for the fossil sql command.

TBD

 (9) There should be a configure option to enable FOSSIL_DEBUG.

TBD

 (10) The src/makemake.tcl script should continue to work - it should still
 build out the various windows makefiles and the unix main.mk file.  In
 other words, autoconf should make use of main.mk.

I plan to change it to directly create the Makefile.in. The cygwin
cross-compiling should work with configure. If you want to keep the
separate Makefile, that doesn't complicate the logic much either, since
the difference between Makefile.in and Cygwin's Makefile is just a
different header. TBD

Joerg
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-15 Thread Eric Junkermann 





On 15 Jun 2011, at 16:28, Andres Perera andre...@zoho.com wrote:



i (now) prefer autotools because i spent some time getting  
comfortable with m4


Yes, I think failure to understand m4, or failure to realise that it  
needs to be understood, is one reason why people end up disliking  
autotools.


Eric___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-15 Thread Mike Meyer 
On Tue, 14 Jun 2011 22:55:18 -0700
Matt Welland estifo...@gmail.com wrote:
 I thought that from an end user perspective all that is needed with autoconf
 is sh.

Not quite true. The problem is that, while every system has a /bin/sh,
different systems use different shells for that: most (but not all)
GNU/Linux systems use bash, the various BSD's use either things
derived from the original v7 sh, OSX switched from a BSD sh to bash at
some point, on SysV-based systems you can find Bourne shell, ksh or
pdksh variants, just to name the obvious ones. You can't even write
for a hypothetical posix shell because /bin/sh isn't posix compliant
on many systems. Which explains the (possibly apocryphal) Bourne
quote: It's easier to write a shell than a portable shell script.

The result is that the autotools config script searches (or searched -
I haven't looked into it in a year or so) the system and $PATH for the
best shell to use. This means whether or not the script actually
works properly depends on which shell it finds (if the best shell
has a bug that some test trips over), which means it can depend on
$PATH and which shells are installed on the system.

In practice, it works fairly well because most systems have bash
installed (if only because GNU/Linux developers tend to write
bash-specific shell scripts, so a lot of software has a run-time
dependency on it) where the config script will find it, and the
autotools tests generally work around the bugs in it.

mike
-- 
Mike Meyer m...@mired.org http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-15 Thread Martin Gagnon 
Le 2011-06-15 à 19:07, Mike Meyer m...@mired.org a écrit :

 On Tue, 14 Jun 2011 22:55:18 -0700
 Matt Welland estifo...@gmail.com wrote:
 I thought that from an end user perspective all that is needed with autoconf
 is sh.
 
 Not quite true. The problem is that, while every system has a /bin/sh,
 different systems use different shells for that: most (but not all)
 GNU/Linux systems use bash, the various BSD's use either things
 derived from the original v7 sh, OSX switched from a BSD sh to bash at
 some point, on SysV-based systems you can find Bourne shell, ksh or
 pdksh variants, just to name the obvious ones. You can't even write
 for a hypothetical posix shell because /bin/sh isn't posix compliant
 on many systems. Which explains the (possibly apocryphal) Bourne
 quote: It's easier to write a shell than a portable shell script.
 
 The result is that the autotools config script searches (or searched -
 I haven't looked into it in a year or so) the system and $PATH for the
 best shell to use. This means whether or not the script actually
 works properly depends on which shell it finds (if the best shell
 has a bug that some test trips over), which means it can depend on
 $PATH and which shells are installed on the system.
 
 In practice, it works fairly well because most systems have bash
 installed (if only because GNU/Linux developers tend to write
 bash-specific shell scripts, so a lot of software has a run-time
 dependency on it) where the config script will find it, and the
 autotools tests generally work around the bugs in it.
 
mike
 -- 
 Mike Meyer m...@mired.org 

So why not keep it how it is and write a Makefile.haiku, the actual Makefile 
work well in almost every other systems anyway...

Even like this, it is easier to build fossil on haiku than on windows anyway...

-- 
Martin
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-14 Thread Twylite 
On 09:59 PM, Nathaniel R. Reindl wrote:
 Is it necessary that it's autoconf?  Or would you take a CMake-based build
 script?
 The GNU autotools have a lot of traction in the community, and a wide
 variety of people are familiar with them.  This makes a compelling
 case alone for adopting the toolset
Unless you intend to build on Windows, in which case you'll maintain a 
separate build system for that platform.  Or you use an IDE, which will 
need its own build files.  In fact, if you use anything other than a 
text console on *nix, you may want to consider a different build tool.

If my opinion counted (it doesn't, I haven't contributed code to Fossil) 
I would support CMake.  But Fossil's sources are heavily preprocessed 
and it may only be possible to build them in a *nix shell environment.

Regards,
Twylite



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-14 Thread Stephan Beal 
On Tue, Jun 14, 2011 at 1:27 AM, Richard Hipp d...@sqlite.org wrote:

 If you have a way other than autoconf to generate a universal build script
 that runs on any unix machine without special software installed, then that
 will be fine.  CMake does not qualify because it is not installed by default
 on most unix boxes.  I think autoconf is probably going to be the only
 general-purpose solution, but I am open to alternatives if you have them.


/bin/sh

it's not nearly as painful as the Auto, my ass! Tools.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-14 Thread Richard Hipp 
On Tue, Jun 14, 2011 at 1:58 AM, Gour-Gadadhara Dasa g...@atmarama.netwrote:


 What about Python dependency? Is it acceptable?


Python is on my iMac and my Linux desktop.  But it is not installed on the
OpenBSD 4.7 system that I use for testing.  Perhaps in a few more years
Python will have become sufficiently universal to be useful for this, but it
is not there yet.  So, no, python is not yet an acceptable dependency given
that autoconf has already demonstrated that a Bourne shell is all you really
need.




 In that case I can think about waf (http://code.google.com/p/waf/) which
 is
 single python script to be included with the project.

 Samba is one bigger project adopting waf.


 Sincerely,
 Gour


 --
 “In the material world, conceptions of good and bad are
 all mental speculations…” (Sri Caitanya Mahaprabhu)

 http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-14 Thread Alexander Vladimirov 
actually autoconf requires GNU M4, and somehow tends to bring automake
and libtool to your system as well.

2011/6/14 Richard Hipp d...@sqlite.org:
 On Tue, Jun 14, 2011 at 1:58 AM, Gour-Gadadhara Dasa g...@atmarama.net
 wrote:

 What about Python dependency? Is it acceptable?

 Python is on my iMac and my Linux desktop.  But it is not installed on the
 OpenBSD 4.7 system that I use for testing.  Perhaps in a few more years
 Python will have become sufficiently universal to be useful for this, but it
 is not there yet.  So, no, python is not yet an acceptable dependency given
 that autoconf has already demonstrated that a Bourne shell is all you really
 need.



 In that case I can think about waf (http://code.google.com/p/waf/) which
 is
 single python script to be included with the project.

 Samba is one bigger project adopting waf.


 Sincerely,
 Gour


 --
 “In the material world, conceptions of good and bad are
 all mental speculations…” (Sri Caitanya Mahaprabhu)

 http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




 --
 D. Richard Hipp
 d...@sqlite.org

 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users





-- 
Alexander Vladimirov idkfa at idkfa dot org dot ru
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-14 Thread Remigiusz Modrzejewski 

On Jun 14, 2011, at 13:37 , Richard Hipp wrote:

 What about Python dependency? Is it acceptable?
 
 Python is on my iMac and my Linux desktop.  But it is not installed on the
 OpenBSD 4.7 system that I use for testing.  Perhaps in a few more years
 Python will have become sufficiently universal to be useful for this, but it
 is not there yet.  So, no, python is not yet an acceptable dependency given
 that autoconf has already demonstrated that a Bourne shell is all you really
 need.


But on the other hand, Python is easier to get on Windows than Bourne shell...
Still with this kind of requirements (should work on *bsd on a toaster) it's 
probably best to stick with autotools, no matter how much pain is that :/


Kind regards,
Remigiusz Modrzejewski



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-14 Thread Remigiusz Modrzejewski 

On Jun 14, 2011, at 13:45 , Alexander Vladimirov wrote:

 actually autoconf requires GNU M4, and somehow tends to bring automake
 and libtool to your system as well.


Yeah, that's for the developers. But users just need to run the Bourne shell 
configure script.


Kind regards,
Remigiusz Modrzejewski



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-14 Thread Ben Summers 
 
 On Jun 14, 2011, at 13:45 , Alexander Vladimirov wrote:
 
 actually autoconf requires GNU M4, and somehow tends to bring automake
 and libtool to your system as well.
 
 
 Yeah, that's for the developers. But users just need to run the Bourne shell 
 configure script.


As an intermediate stage, a simple script to put the output of uname -s into 
the Makefile might be a way to get going?

  http://fossil-scm.org/index.html/timeline?r=configure-make

autotools are a bit of a nightmare, and possibly overkill for a project which 
is so inherently portable and self-contained.

Ben


--
http://bens.me.uk/


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-14 Thread Kulcsár Ferenc 

2011-06-14 01:27 keltezéssel, Richard Hipp írta:



On Mon, Jun 13, 2011 at 7:07 PM, Steve Havelka smh...@gmail.com 
mailto:smh...@gmail.com wrote:


Is it necessary that it's autoconf?  Or would you take a
CMake-based build script?


ccmake is not installed by default on either my iMac nor my SuSE Linux 
desktop.  So it a a non-starter.


If you have a way other than autoconf to generate a universal build 
script that runs on any unix machine without special software 
installed, then that will be fine.  CMake does not qualify because it 
is not installed by default on most unix boxes.  I think autoconf is 
probably going to be the only general-purpose solution, but I am open 
to alternatives if you have them.




What about autosetup?

You  find informations here: http://msteveb.github.com/autosetup/

Regards,
Feri
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-14 Thread Remigiusz Modrzejewski 

On Jun 14, 2011, at 14:06 , Ben Summers wrote:

 As an intermediate stage, a simple script to put the output of uname -s into 
 the Makefile might be a way to get going?
 
  http://fossil-scm.org/index.html/timeline?r=configure-make
 
 autotools are a bit of a nightmare, and possibly overkill for a project which 
 is so inherently portable and self-contained.


Nope, there's need for more than just that - see the first post. You can try to 
get all that done without autohell, but I guess that shortly it will reach the 
same amount of pain. The only other way I see it is if Waf or some other nicer 
buildsystem could emit a configure shell script...

Gour, can Waf do that?


Kind regards,
Remigiusz Modrzejewski



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-14 Thread Stephan Beal 
On Tue, Jun 14, 2011 at 5:25 PM, Williams, Brian
bwilli...@informatica.comwrote:

 Has anyone thrown themselves on this grenade yet?

 If not, I can take a look at autoconf.


If you haven't already got any grey hairs then you'll have some soon.

Good luck!

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-14 Thread Richard Hipp 
On Tue, Jun 14, 2011 at 11:25 AM, Williams, Brian bwilli...@informatica.com
 wrote:

 Has anyone thrown themselves on this grenade yet?

 If not, I can take a look at autoconf.


I got a chat message from someone who said they would take a look.

Surely the autoconf for Fossil won't be to hard?  All it needs to do is
check for a couple of libraries and set a few options based on --with-X
flags.




 -Original Message-
 From: fossil-users-boun...@lists.fossil-scm.org
 [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of
 Remigiusz Modrzejewski
 Sent: Tuesday, June 14, 2011 7:12 AM
 To: fossil-users@lists.fossil-scm.org
 Subject: Re: [fossil-users] Needed: volunteer to autoconf Fossil


 On Jun 14, 2011, at 14:06 , Ben Summers wrote:

  As an intermediate stage, a simple script to put the output of uname
 -s into the Makefile might be a way to get going?
 
   http://fossil-scm.org/index.html/timeline?r=configure-make
 
  autotools are a bit of a nightmare, and possibly overkill for a
 project which is so inherently portable and self-contained.


 Nope, there's need for more than just that - see the first post. You can
 try to get all that done without autohell, but I guess that shortly it
 will reach the same amount of pain. The only other way I see it is if
 Waf or some other nicer buildsystem could emit a configure shell
 script...

 Gour, can Waf do that?


 Kind regards,
 Remigiusz Modrzejewski



 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-14 Thread Stephan Beal 
On Tue, Jun 14, 2011 at 5:35 PM, Richard Hipp d...@sqlite.org wrote:

 Surely the autoconf for Fossil won't be to hard?  All it needs to do is
 check for a couple of libraries and set a few options based on --with-X
 flags.


In my experience, it's not getting the project set up which is problematic,
but fixing all the macro incompatibilities every time the auto tools are
updated by one minor revision (and i was never quite sure what they were
automating, since i always had to expend so much effort to make them
work). i spent hundreds of hours back at the start of the century fighting
with it, but eventually gave up on them, wrote my own version accommodating
only Unix-like systems hosting GNU tools, and that's all i've used every
since.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-14 Thread Mike Meyer 
On Mon, 13 Jun 2011 19:27:49 -0400
Richard Hipp d...@sqlite.org wrote:

 On Mon, Jun 13, 2011 at 7:07 PM, Steve Havelka smh...@gmail.com wrote:
 
  Is it necessary that it's autoconf?  Or would you take a CMake-based build
  script?
 ccmake is not installed by default on either my iMac nor my SuSE Linux
 desktop.  So it a a non-starter.
 
 If you have a way other than autoconf to generate a universal build script
 that runs on any unix machine without special software installed, then that
 will be fine.  CMake does not qualify because it is not installed by default
 on most unix boxes.  I think autoconf is probably going to be the only
 general-purpose solution, but I am open to alternatives if you have them.

I feel compelled to point out that installed by default on most unix
boxes isn't a realistic requirement.  I'd say it eliminates autoconf
because it isn't installed by default on any of *my* Unix boxes (all
running OpenSolaris or FreeBSD). For that matter, a C compiler isn't
installed by default on OpenSolaris or most of the GNU/Linux distros
I'm familiar with, so by that definition you can't build fossil
without special software installed on those systems.

For most unix and unix-like systems, a more appropriate requirement
would be is available from the package system. I.e. - it's something
that can be trivially installed, without having to configure or build
or chase dependencies for it. Since Windows and OSX don't come with
package systems, that won't work for them, but having a binary build
available from the authors should meet the goal of being trivial to
install.

mike
-- 
Mike Meyer m...@mired.org http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-14 Thread Lluís Batlle i Rossell 
On Tue, Jun 14, 2011 at 05:42:49PM +0200, Stephan Beal wrote:
 Another suggestion nobody has made yet: jam. It can be distributed in
 static-binary form directly with the source tree (i've seen this done in a
 couple projects, and i know it can build on some rather obscure systems). i
 can't personally speak for jam's usability - read about it but never used it
 myself.

It takes 2GB of RAM for jam to build boost, compilers and linkers apart. I don't
think it scales any well.

In my projects I use cmake, but I don't know how portable it is beyond the usual
OSes around. I've used it succesfully for cross-compilation too, without
troubles.

I clearly understand the advantages of a good autotools *result*: a shell script
that works in many places. That's outstanding compared to the rest of tools
proposed, so although I will not do the work on making fossil autotools-ready, I
understand the people wanting it.

Regards,
Lluís.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-14 Thread Mike Meyer 
On Tue, 14 Jun 2011 17:37:06 -0400
David Slocombe sloco...@vex.net wrote:

 But autotools should come first as it both supports the above and
 goes at least a long way to helping all the other folks who aren't
 plugged into some Linux distribution's binary package system.

Is autotools the only such tool the fedora committers support? Seems
like a lot of things don't require them, and many of those that do
require patching by hand to build anyway. Of the 23,054 package
Makefiles in the FreeBSD ports tree, only 1732 use any of the
autotools (most of those seem to be libtool), and of those, 1165 need
further patching(*).

  mike

Those are *very* rough numbers, based on checking for the
USE_AUTOTOOLS variable in the Makefiles and whether or not the port
has a files directory (which holds patches). Lots of things could
throw those numbers off, but unless something really weird is going
on, they should be the right order of magnitude.

-- 
Mike Meyer m...@mired.org http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-14 Thread Graeme Gill 
Stephan Beal wrote:
 Another suggestion nobody has made yet: jam. It can be distributed in
 static-binary form directly with the source tree (i've seen this done in a
 couple projects, and i know it can build on some rather obscure systems). i
 can't personally speak for jam's usability - read about it but never used it
 myself.

I use Jam in my cross-system project, but I don't like the default
Jambase, and completely re-wrote it to suite my ideas of how a build
system should work. I rather like Jam itself since it's quite flexible
and works well on the systems I use if for, with very few system specific
cases in the Jamfiles, but (not surprisingly) people who want to build
my software complain about not using a standard system like AutoTools,
even though such systems aren't suitable for MSWin/VC++ type environments.
The bottom line is that it does make everyone equal - they all have to
install/compile Jam first!  (Jam is available on some Linux systems as a
standard package.)

[ My experience with CMake hasn't endeared it to me. AutoTools is
pretty awful, and always seems to be breaking. QMake seems cleaner
than most systems. I'm sticking with Jam for my code, as it's clean
and I can now maintain it easily.]

Graeme Gill.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-14 Thread Matt Welland 
All of these alternative build systems are a PITA on one system or another.
If it requires jam, cmake or anything that requires installing prerequisites
9 times out of 10 I won't even try that software unless there is a binary
install available somewhere or a pre-assembled Makefile.

I thought that from an end user perspective all that is needed with autoconf
is sh. The requirement is on the developer to run autoconf before making the
tar. I thought autoconf itself is not needed on the platform where the build
is being done, correct??

For fossil you could keep the files generated by autoconf (not the
./configure step but the initialization step) checked in. Then it is just
./configure  make install on most systems. For anything weird (e.g.
windows) provide a Makefile.win32 or similar.

Alexanders suggestion of premake4 is the only one that piqued my interest.
Distribute the source along with fossil and use autoconf to build it and
then premake4 to build fossil ... just kidding ... although for some twisted
reason that wacky idea actually appeals to me.

On Tue, Jun 14, 2011 at 10:18 PM, Martin Gagnon eme...@gmail.com wrote:

 Le 2011-06-14 à 22:19, Graeme Gill grae...@argyllcms.com a écrit :

  Stephan Beal wrote:
  Another suggestion nobody has made yet: jam. It can be distributed in
  static-binary form directly with the source tree (i've seen this done in
 a
  couple projects, and i know it can build on some rather obscure
 systems). i
  can't personally speak for jam's usability - read about it but never
 used it
  myself.
 
  I use Jam in my cross-system project, but I don't like the default
  Jambase, and completely re-wrote it to suite my ideas of how a build
  system should work. I rather like Jam itself since it's quite flexible
  and works well on the systems I use if for, with very few system specific
  cases in the Jamfiles, but (not surprisingly) people who want to build
  my software complain about not using a standard system like AutoTools,
  even though such systems aren't suitable for MSWin/VC++ type
 environments.
  The bottom line is that it does make everyone equal - they all have to
  install/compile Jam first!  (Jam is available on some Linux systems as a
  standard package.)
 
  [ My experience with CMake hasn't endeared it to me. AutoTools is
  pretty awful, and always seems to be breaking. QMake seems cleaner
  than most systems. I'm sticking with Jam for my code, as it's clean
  and I can now maintain it easily.]
 
  Graeme Gill.
 

 All that thread start when someone post about haiku that need different
 libs flags in order to link properly. If a OS like Haiku don't have this
 jam, all that is pretty pointless.

 And for myself which use QNX, I really don't want to think about how I'll
 make work jam on it. It was actually already compiling on QNX with the
 standard Makefile anyway.

 As others pointed it out before, I really think that to automaticaly
 generate this Makefile, if we really have to go that way, we should need
 something already on all system; like /bin/sh. So is the case of the
 configure script produced by this autowhatever, but one maintainers need the
 too have autowhatever installed to maintain the resulting configure script,
 which is not as bad as requiring extra tool on every system that build
 fossil. Is it an acceptable trade off knowing how much everybody love this
 autowhatever?

 --
 Martin
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-13 Thread Ramon Ribó 

 (4) The result should have a 0 Fail-Score according to
 https://www.theopensourceway.org/wiki/How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL


This point is not easy to acomplish. Take into acount the following
statement in the previous page:


You've written your own source control for this code [ +30 points of FAIL ]

RR
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-13 Thread Alexander Vladimirov 
just my 2 cents..

maybe premake4 could make a sense?
quoting their site (http://industriousone.com/what-premake):
Premake is a plain old C application, distributed as a single
executable file. It is small, weighing in at around 200K. It does not
require any additional libraries or runtimes to be installed, and
should build and run pretty much anywhere. It is currently being
tested and used on Windows, Mac OS X, Linux, and other POSIX
environments. It uses only a handful of platform dependent routines
(directory management, mostly). Adding support for additional toolsets
and languages is straightforward. The source code is available under
the BSD License. The source code is hosted on BitBucket; file
downloads are hosted on SourceForge.


2011/6/13 Ramon Ribó ram...@compassis.com

 
  (4) The result should have a 0 Fail-Score according to
  https://www.theopensourceway.org/wiki/How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL
 

 This point is not easy to acomplish. Take into acount the following
 statement in the previous page:


 You've written your own source control for this code [ +30 points of FAIL ]

 RR
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



--
Alexander Vladimirov idkfa at idkfa dot org dot ru
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-13 Thread Remigiusz Modrzejewski 

On Jun 13, 2011, at 16:03 , Richard Hipp wrote:
 
 (4) The result should have a 0 Fail-Score according to
 https://www.theopensourceway.org/wiki/How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL

Does this imply introduction of properly numbered releases? ;)
Your project does not do versioned releases [ +20 points of FAIL ]

Kind regards,
Remigiusz Modrzejewski



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-13 Thread Richard Hipp 
On Mon, Jun 13, 2011 at 10:25 AM, Ramon Ribó ram...@compassis.com wrote:

 
  (4) The result should have a 0 Fail-Score according to
 
 https://www.theopensourceway.org/wiki/How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL
 

 This point is not easy to acomplish. Take into acount the following
 statement in the previous page:


 You've written your own source control for this code [ +30 points of FAIL ]


Spot latter amended this to to add the clause:  and your project is not a
source control system.  So this is not an issue.




 RR
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-13 Thread Richard Hipp 
On Mon, Jun 13, 2011 at 10:31 AM, Remigiusz Modrzejewski l...@maxnet.org.pl
 wrote:


 On Jun 13, 2011, at 16:03 , Richard Hipp wrote:
 
  (4) The result should have a 0 Fail-Score according to
 
 https://www.theopensourceway.org/wiki/How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL

 Does this imply introduction of properly numbered releases? ;)
 Your project does not do versioned releases [ +20 points of FAIL ]


Yes.  I'll make changes so that the next release is version 1.0.




 Kind regards,
 Remigiusz Modrzejewski



 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-13 Thread Nathaniel R. Reindl 
On Mon, Jun 13, 2011 at 6:07 PM, Steve Havelka smh...@gmail.com wrote:
 Is it necessary that it's autoconf?  Or would you take a CMake-based build
 script?

The GNU autotools have a lot of traction in the community, and a wide
variety of people are familiar with them.  This makes a compelling
case alone for adopting the toolset, as maddening as it may be, let
alone how much it may counter the whole bridge-jumping metaphor your
parents used to tell you as a kid.

-- 
Nathaniel R. Reindl
We have computers which can beat your computers.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-13 Thread Richard Hipp 
On Mon, Jun 13, 2011 at 7:07 PM, Steve Havelka smh...@gmail.com wrote:

 Is it necessary that it's autoconf?  Or would you take a CMake-based build
 script?


ccmake is not installed by default on either my iMac nor my SuSE Linux
desktop.  So it a a non-starter.

If you have a way other than autoconf to generate a universal build script
that runs on any unix machine without special software installed, then that
will be fine.  CMake does not qualify because it is not installed by default
on most unix boxes.  I think autoconf is probably going to be the only
general-purpose solution, but I am open to alternatives if you have them.




 thanks,
 Steve

 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Needed: volunteer to autoconf Fossil

2011-06-13 Thread Gour-Gadadhara Dasa 
On Mon, 13 Jun 2011 19:27:49 -0400
Richard Hipp d...@sqlite.org wrote:

 If you have a way other than autoconf to generate a universal build
 script that runs on any unix machine without special software
 installed, then that will be fine.  CMake does not qualify because it
 is not installed by default on most unix boxes.  I think autoconf is
 probably going to be the only general-purpose solution, but I am open
 to alternatives if you have them.

What about Python dependency? Is it acceptable?

In that case I can think about waf (http://code.google.com/p/waf/) which is
single python script to be included with the project.

Samba is one bigger project adopting waf.


Sincerely,
Gour


-- 
“In the material world, conceptions of good and bad are
all mental speculations…” (Sri Caitanya Mahaprabhu)

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810




signature.asc
Description: PGP signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users