[fossil-users] Needed: volunteer to autoconf Fossil

[Richard Hipp]

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. 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...)

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.

Objectives (not an any particular order):

(1) "./configure; make install" should work on all unix systems

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

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

(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

(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.

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

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

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

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

(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.

(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!

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

[Ramon Ribó]

Post by Richard Hipp
(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

[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.

Post by Ramon Ribó

Post by Richard Hipp
(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
You've written your own source control for this code [ +30 points of FAIL ]
RR
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

--
Alexander Vladimirov <idkfa at idkfa dot org dot ru>

[Richard Hipp]

Post by Richard Hipp

Post by Richard Hipp
(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
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.

Post by Richard Hipp
RR
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Remigiusz Modrzejewski]

Post by Richard Hipp
(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

[Richard Hipp]

Post by Richard Hipp

Post by Richard Hipp
(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".

Post by Richard Hipp
Kind regards,
Remigiusz Modrzejewski
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Steve Havelka]

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


thanks,
Steve

[Nathaniel R. Reindl]

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.

[Twylite]

Post by Nathaniel R. Reindl

Post by Steve Havelka
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

[Richard Hipp]

Post by Steve Havelka
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.

Post by Steve Havelka
thanks,
Steve
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Gour-Gadadhara Dasa]

On Mon, 13 Jun 2011 19:27:49 -0400

Post by Richard Hipp
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

[Richard Hipp]

Post by Gour-Gadadhara Dasa
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.

Post by Gour-Gadadhara Dasa
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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Remigiusz Modrzejewski]

Post by Richard Hipp

Post by Gour-Gadadhara Dasa
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

[Alexander Vladimirov]

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

Post by Gour-Gadadhara Dasa
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.

Post by Gour-Gadadhara Dasa
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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Remigiusz Modrzejewski]

Post by Alexander Vladimirov
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

[Stephan Beal]

Post by Richard Hipp
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.

[Michael Richter]

Post by Stephan Beal

Post by Richard Hipp
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.

[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*....

[Ross Berteig]

(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.)

For the record, the goal of MSYS is exactly to provide the
prerequist tools needed so that unrolling a tarball then saying
"./configure; make" can do something sensible on Windows. One key
is providing a minimal but complete set of the usual tools (cp,
mv, rm, tar, m4, sh, bash, ...) bundled in a way that allows for
straight-forward setup. The compilers are MinGW, and generate
native Windows executables.

Cygwin is a more complete *nix emulation that runs within
Windows, and provides a nearly complete *nix experience,
including a package manager, X windows, and all the bells and
whistles. The problem is that the natural Cygwin compilers build
executables that assume that Cygwin is installed, and use its
mapping of *nix names of things in preference to Windows names.
This results in an environment that is friendly to a full-time
*nix user, but is unnecessarily difficult for a normal Windows
user. It is possible to build Windows native executables from
Cygwin, of course, but that is not the default behavior.

In my experience, it is likely that MSYS is sufficient as long as
the gross platform differences between unix and Windows are
accounted for in the application itself. For example, a program
that uses X windows without a cross platform GUI toolkit will be
nearly impossible to port to Windows without significant effort,
even if you can get its build system compile it there.

Fossil's prerequisits are simple and very portable. It's already
easy to build it natively on Windows (I do it with MinGW at a
normal Command prompt using Gnu Make and the usual suspect tools
distributed for Windows by the GnuWin32 project.) It should be
straightforward to get a autotools to create a configure script
that works with bash as provided by MSYS.


Ross Berteig ***@CheshireEng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
[phone]
[phone] FAX

[Kulcsár Ferenc]

Post by Steve Havelka
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

[Mike Meyer]

On Mon, 13 Jun 2011 19:27:49 -0400

Post by Richard Hipp

Post by Steve Havelka
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

[Joshua Paine]

Post by Mike Meyer
I feel compelled to point out that "installed by default on most unix
boxes" isn't a realistic requirement. ... a C compiler isn't
"installed by default" on OpenSolaris or most of the GNU/Linux distros...
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.

I agree, and this matches my experience as well.

I install most software on my linux boxes via the package system. If I'm
going to compile anything at all, I have to intentionally install
further packages for the purpose.

I do prefer that the dependencies be either common or not-huge. And if
e.g. you require Python, it's important that you not require the latest
Python, as I may have existing apps running on an older version with no
desire to upgrade them or juggle multiple versions.

[David Slocombe]

Post by Mike Meyer
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.

I'm jumping in here without reading the whole thread, but may I just
point out that once autotools has been made to work *fairly* well, it
should be possible to find at least a Fedora "maintainer" to pick up the
relatively minor additional task of making an RPM and getting it into Fedora's "yum"
repository. This in turn should make it easier for other distributions
to package it. And that route should take care of many people's needs
(for Linux at least).

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.

I know nothing about the Mac, but it's worth noting that
Fedora has a very extensive system for building Windows binaries
now, using mingw (i.e. building them *within* the same packaging
system used to build the Linux RPMs -- cross-compiling on Linux).
I wish I knew more about it. But I see the mingw versions of
libraries for a long list of things flying by as I rapidly scan the
nightly build report. I'd be surprised if those didn't cover
everything Fossil was dependent on. Perhaps the same "maintainer"
who picks up Fossil can be persuaded to do a Windows package too.
(I'm not sure what form the "package" takes for Windows.)

Oh! Googling just gave me the link on this topic:
http://fedoraproject.org/wiki/Packaging/MinGW . Well, that's
more than *I* can digest right now! But perhaps someone will
be interested enough to investigate further.

[Mike Meyer]

On Tue, 14 Jun 2011 17:37:06 -0400

Post by David Slocombe
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.

[Richard Hipp]

Post by Steve Havelka
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?

Note that Fossil has a two-stage build process. First it builds some C
programs that are used to pre-process the C code. It then runs these C
programs to convert the code in the source tree into new C code. The
converted C code is then compiled by the second phase to generate the Fossil
executable. Traditional unix "make" has no difficulty handling a two-phase
build like this. But MSVC seems unable to do it. I observe that cmake
claims to be able to generate MSVC projects. Does this mean that cmake is
also incapable of doing a two-phase build? Or has cmake found some way
around the limitations of MSVC?

Additional information on the Fossil build process:
http://www.fossil-scm.org/fossil/doc/trunk/www/makefile.wiki

Post by Steve Havelka
thanks,
Steve
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Lluís Batlle i Rossell]

Post by Richard Hipp

Post by Steve Havelka
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?
Note that Fossil has a two-stage build process. First it builds some C
programs that are used to pre-process the C code. It then runs these C
programs to convert the code in the source tree into new C code. The
converted C code is then compiled by the second phase to generate the Fossil
executable. Traditional unix "make" has no difficulty handling a two-phase
build like this. But MSVC seems unable to do it. I observe that cmake
claims to be able to generate MSVC projects. Does this mean that cmake is
also incapable of doing a two-phase build? Or has cmake found some way
around the limitations of MSVC?

We use things like this in cmake. It allows 'custom commands'. We mostly use the
"nmake makefiles" in cmake for msvc, instead of projects, but I think all works
in projects too.

cmake allows defining "pre-build" custom commands, intermediate targets previous
to the building (like you would do in the usual make), ...

Having CMakeLists.txt files in fossil could serve as a test for cmake helping or
not.

[Arjen Markus]

Hello,

Post by Lluís Batlle i Rossell

Post by Richard Hipp

Post by Steve Havelka
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?
Note that Fossil has a two-stage build process. First it builds some C
programs that are used to pre-process the C code. It then runs these C
programs to convert the code in the source tree into new C code. The
converted C code is then compiled by the second phase to generate the Fossil
executable. Traditional unix "make" has no difficulty handling a two-phase
build like this. But MSVC seems unable to do it. I observe that cmake
claims to be able to generate MSVC projects. Does this mean that cmake is
also incapable of doing a two-phase build? Or has cmake found some way
around the limitations of MSVC?

We use things like this in cmake. It allows 'custom commands'. We mostly use the
"nmake makefiles" in cmake for msvc, instead of projects, but I think all works
in projects too.
cmake allows defining "pre-build" custom commands, intermediate targets previous
to the building (like you would do in the usual make), ...
Having CMakeLists.txt files in fossil could serve as a test for cmake helping or
not.

In the PLplot project (http://plplot.sf.net) we use CMake for a lot of
pre- and postprocessing stuff as well. And I have successfully used the
generated solution and project files to build PLplot using Visual
Studio. (VS does allow you to define pre-compile and post-build steps,
but it is rather cumbersome)

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.

[Thomas Schnurrenberger]

Post by Richard Hipp

Post by Steve Havelka
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.

[Ben Summers]

Post by Remigiusz Modrzejewski

Post by Alexander Vladimirov
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/

[Remigiusz Modrzejewski]

Post by Ben Summers
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

[Williams, Brian]

Has anyone thrown themselves on this grenade yet?

If not, I can take a look at autoconf.


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

Post by Ben Summers
As an intermediate stage, a simple script to put the output of uname

-s into the Makefile might be a way to get going?

Post by Ben Summers
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

[Stephan Beal]

On Tue, Jun 14, 2011 at 5:25 PM, Williams, Brian

Post by Williams, Brian
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!

[Richard Hipp]

Post by Williams, Brian
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-XXXXX
flags.

Post by Williams, Brian
-----Original Message-----
Remigiusz Modrzejewski
Sent: Tuesday, June 14, 2011 7:12 AM
Subject: Re: [fossil-users] Needed: volunteer to autoconf Fossil

Post by Ben Summers
As an intermediate stage, a simple script to put the output of uname

-s into the Makefile might be a way to get going?

Post by Ben Summers
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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Stephan Beal]

Post by Richard Hipp
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-XXXXX
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
"auto"mating, 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]

Post by Richard Hipp
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-XXXXX
flags.

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.

The boost project used jam for years - i don't know if they still are,
though.

[Lluís Batlle i Rossell]

Post by Stephan Beal
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.

[Graeme Gill]

Post by Stephan Beal
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.

[Martin Gagnon]

Post by Graeme Gill

Post by Stephan Beal
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?

[Graeme Gill]

Post by Martin Gagnon
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.

Pretty easy to port, especially if the OS is similar to UNIX.

Graeme Gill.

[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.

Post by Stephan Beal

Post by Graeme Gill

Post by Stephan Beal
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

Post by Graeme Gill

Post by Stephan Beal
couple projects, and i know it can build on some rather obscure

systems). i

Post by Graeme Gill

Post by Stephan Beal
can't personally speak for jam's usability - read about it but never

used it

Post by Graeme Gill

Post by Stephan Beal
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.

Post by Graeme Gill
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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Michal Suchanek]

Post by 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??

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

[Alexander Vladimirov]

how abouth this: http://buildconf.brlcad.org

Post by Michal Suchanek

Post by 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??

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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Michal Suchanek]

Post by Alexander Vladimirov
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

[Twylite]

Post by Matt Welland
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

[Michal Suchanek]

Post by Twylite

Post by Matt Welland
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

[Graeme Gill]

Post by Michal Suchanek
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.

Graeme Gill.

[Arjen Markus]

Hello Graeme,

Post by Graeme Gill

Post by Michal Suchanek
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.

[Andres Perera]

Post by Arjen Markus
Hello Graeme,

Post by Graeme Gill

Post by Michal Suchanek
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.

if fossil needs to support windows builds w/o cygwin/other unix env
for windows, and simultaneously support unix builds, then cmake is
really the best option

cmake is also remarkably faster then autotools and the macro language
is less picky than m4

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

Post by Arjen Markus
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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Eric Junkermann]

Post by Andres Perera
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

[Lluís Batlle i Rossell]

Post by Graeme Gill

Post by Michal Suchanek
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.
Graeme Gill.

Unix multiplatform projects to be built with the msvc compiler usually provide
makefiles for nmake, or projects for visual studio.

The wxwidgets project provide some kind of autotools-generated "configure.exe",
iirc. I don't know where they get it from.

For mingw, some people use the msys tools to run 'configure' scripts.

At least this is the picture I have in my mind.

[Mike Meyer]

On Tue, 14 Jun 2011 22:55:18 -0700

Post by Matt Welland
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

[Martin Gagnon]

Post by Mike Meyer
On Tue, 14 Jun 2011 22:55:18 -0700

Post by Matt Welland
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
--

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...

[Williams, Brian]

I don't expect it to be.





From: fossil-users-***@lists.fossil-scm.org
[mailto:fossil-users-***@lists.fossil-scm.org] On Behalf Of Richard
Hipp
Sent: Tuesday, June 14, 2011 10:35 AM
To: fossil-***@lists.fossil-scm.org
Subject: Re: [fossil-users] Needed: volunteer to autoconf Fossil





On Tue, Jun 14, 2011 at 11:25 AM, Williams, Brian
<***@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-XXXXX flags.




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

Post by Ben Summers
As an intermediate stage, a simple script to put the output of

uname
-s into the Makefile might be a way to get going?

Post by Ben Summers
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-***@lists.fossil-scm.org

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

http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Joerg Sonnenberger]

Post by Richard Hipp
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.

Post by Richard Hipp
(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.

Post by Richard Hipp
(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.

Post by Richard Hipp
(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?

Post by Richard Hipp
(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.

Post by Richard Hipp
(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?

Post by Richard Hipp
(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.

Post by Richard Hipp
(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.

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

TBD

Post by Richard Hipp
(9) There should be a configure option to enable FOSSIL_DEBUG.

TBD

Post by Richard Hipp
(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

[Altu Faltu]

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

[Richard Hipp]

Post by Altu Faltu
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.)

Post by Altu Faltu
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[h***@psh-consulting.de]

I'm building fossil for and embedded ARM-system in a crosscompiling environment.
These controlers are used on our NAS-Servers which hosts our fossil
repositories. This is not a complete unix environment. But I was happy all the
time with the unix makefile. How do I handle this in future?
 
Regards
Hein

 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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

--
D. Richard Hipp

 

[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-***@lists.fossil-scm.org
Subject: Re: [fossil-users] Needed: volunteer to autoconf Fossil


On Thu, Jun 16, 2011 at 10:33 PM, Altu Faltu < ***@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-***@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



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

[Martin Gagnon]

Post by 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.

[snip]

That's would be good but a bit more complicate to do....

Even right now, mingw Makefile is not automatically synced with the main unix Makefile. (if there's no tcl script that generate them together, I believe the main one is generate that way...)