autoconf and erlang

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

autoconf and erlang

Hal Snyder-2
We are using autoconf to build all our Erlang apps these days.
It helps with the following things:

a. portability (we need to run on several platforms)

b. selection of development vs. production environments when building

c. integrates well with packaging system (pkgsrc) which helps config &
   release management

This sort of relates to EPAN idea and recent publicity thread, if a
consistent build setup can be developed.


Here's one simple offering. To use, put it into otp.m4 or such in
$PREFIX/share/aclocal. In configure.ac, include the line
AX_WITH_ERL_RUN_TOP. It will look around for an Erlang run-time
distribution but allow you to override its best guess by specifying a
value e.g. sh configure --with-erl-run-top=/u1/lib/erlang.


dnl @synopsis AX_WITH_ERL_RUN_TOP()
##
## Locates an installed Erlang run-time tree, placing the result in the precious
## variable $ERL_RUN_TOP. Accepts a present $ERL_RUN_TOP, then --with-erl-top.
##
## Example:
##
##   AX_WITH_ERL_RUN_TOP
##
AC_DEFUN([AX_WITH_ERL_RUN_TOP],[
  AC_MSG_CHECKING([for --with-erl-run-top])
  AC_ARG_WITH([erl-run-top],
    AC_HELP_STRING([--with-erl-run-top],[Erlang run-time, e.g. /usr/pkg/lib/erlang]),
    [ERL_RUN_TOP="$withval"],
    [ERL_RUN_TOP=$prefix/lib/erlang
     if test -d "$ERL_RUN_TOP"; then
       :
     else
       AC_MSG_RESULT(no)
       AC_MSG_ERROR([cannot find ERL_RUN_TOP])
     fi
    ])
  AC_MSG_RESULT([$ERL_RUN_TOP])
  AC_SUBST([ERL_RUN_TOP])
])


Reply | Threaded
Open this post in threaded view
|

autoconf and erlang

Luke Gorrie-3
Hal Snyder <hal> writes:

> We are using autoconf to build all our Erlang apps these days.
> It helps with the following things:
>
> a. portability (we need to run on several platforms)
>
> b. selection of development vs. production environments when building
>
> c. integrates well with packaging system (pkgsrc) which helps config &
>    release management
>
> This sort of relates to EPAN idea and recent publicity thread, if a
> consistent build setup can be developed.

The Jungerl does this somewhat. There we have a top-level autoconf
that is shared by all applications and some Makefile includes that
take care of all the usual stuff. Anyone should feel free to extend
these.

I remember having troubles when we recently tried to build Jungerl on
Joe's machine, which is a pity, but I don't remember exactly what went
wrong. I'm trying to fix a couple of simple things just now, but,
really, Sourceforge is unusable these days.

By the way, I've been playing a little bit with these "next
generation" version control tools intended to replace CVS. I can
report that Darcs (http://abridgegame.org/darcs/) is worth a look.

-Luke



Reply | Threaded
Open this post in threaded view
|

autoconf and erlang

Vlad Dumitrescu-4
From: "Luke Gorrie" <luke>

> By the way, I've been playing a little bit with these "next
> generation" version control tools intended to replace CVS. I can
> report that Darcs (http://abridgegame.org/darcs/) is worth a look.

I've checked it and it is interesting, but it doesn't feel quite right. I
think Subversion http://subversion.tigris.org might be better, not the least
because the commands are almost like CVS. The drawback is that there are no
sites yet that host Subversion servers for free.

regards,
/Vlad



Reply | Threaded
Open this post in threaded view
|

OT: revision control [was: Re: autoconf and erlang]

Dustin Sallings

On May 12, 2004, at 11:23, Vlad Dumitrescu wrote:

> I've checked it and it is interesting, but it doesn't feel quite
> right. I
> think Subversion http://subversion.tigris.org might be better, not the
> least
> because the commands are almost like CVS. The drawback is that there
> are no
> sites yet that host Subversion servers for free.

        Please don't do this.  I think decentralization is important for open
source projects.  The centralized model makes it too difficult for
individuals to maintain their own trees, manage changes against head of
line, and creates a scaling problem when projects become more popular.

        Choosing a solution just because it's most like the one many people
have been using for a long time is a bad idea.  There are lots of
distributed revision control systems available these days that go way
beyond solving small problems in CVS structure and provide features
that fit very naturally into an open source development environment
where contributors from all over the world have varying quality of
connectivity.  And honestly, most of the time all you're doing is
editing files and committing changes, maybe pulling in changes from a
source repository, right?

        I use arch for almost all of my projects.  Branching is so easy there,
anyone can understand it with little effort and it's become the normal
mechanism for contributing to other people's projects.  I have private
branches of several applications I'm tracking and all that's required
from my upstream is a vanilla http server to which the head of line
commits are published.  More importantly, the repository is made up of
plain files (in tar files) that are immutable and easy to parse without
having any arch tools to check out a tree.  Makes replication a snap
since the tree structure isn't changing (with the exception of a lock
that gets passed around on the write tree).

        Darcs is a very nice set of improvements in some areas of arch
(although I believe it's missing in a few others that I use).  In
particular, you can basically use a mailing list to track changes to a
tree.  It's possible to branch a project, track head of line, make
changes and send them back without even having an internet connection.  
The repository is made up of pretty plain files again.  (I've not used
this one enough since I couldn't get it compiled at the time I ended up
using arch for everything)

        monotone is another example, although one I haven't personally tried
yet.  The docs look pretty good, though.  The one thing that makes me a
bit weary of this one is that the repository is a mutable opaque store
(like subversion).


        The fact that a server is required for subversion means you're going
to have the same scalability issues sourceforge has if a project gets
popular.  The central servers gets too busy and it gets slow to submit
changes or check stuff out or whatever.  The fact that you can't find a
site to host your project on subversion also suggests it might be a bad
choice.  I have several sites hosting my arch repositories (stock OS X
apache, NetBSD custom Apache install, thttpd, whatever 1and1 provides
for their cheap hosting solution) and all they know is I've got files
sitting in my web space.  No special apache modules (which would have
to be ported to yaws, of course), no cgis, just the files that make up
my dev trees.

--
Dustin Sallings



Reply | Threaded
Open this post in threaded view
|

autoconf and erlang

Peter-Henry Mander-6
In reply to this post by Luke Gorrie-3

Although the idea of using a revision control system built in Haskell is
cool, would it not be more practical/expedient to use e.g. Subversion
(which we contentedly use) or Arch? What would darcs give us that over
them? If there are major advantages in using a functional language, why
not create evcs too? :-)

Using Subversion has avoided tying us permanently to network connections
and allows us to work remotely, which a life saver in unexpected
circumstances! The Swedes would laugh in hysterics to see the effect a
few inches of snow has on British society!

Pete.

On Wed, 12 May 2004 17:09:26 +0200
Luke Gorrie <luke> wrote:

> Hal Snyder <hal> writes:
>
> > We are using autoconf to build all our Erlang apps these days.
> > It helps with the following things:
> >
> > a. portability (we need to run on several platforms)
> >
> > b. selection of development vs. production environments when
> > building
> >
> > c. integrates well with packaging system (pkgsrc) which helps config
> > &
> >    release management
> >
> > This sort of relates to EPAN idea and recent publicity thread, if a
> > consistent build setup can be developed.
>
> The Jungerl does this somewhat. There we have a top-level autoconf
> that is shared by all applications and some Makefile includes that
> take care of all the usual stuff. Anyone should feel free to extend
> these.
>
> I remember having troubles when we recently tried to build Jungerl on
> Joe's machine, which is a pity, but I don't remember exactly what went
> wrong. I'm trying to fix a couple of simple things just now, but,
> really, Sourceforge is unusable these days.
>
> By the way, I've been playing a little bit with these "next
> generation" version control tools intended to replace CVS. I can
> report that Darcs (http://abridgegame.org/darcs/) is worth a look.
>
> -Luke
>


--
Peter-Henry Mander
BSc hons. Comp Sci & Cyb
Software Engineer
Newport Networks Limited

Tel: + 44 (0) 1494 470 681


Reply | Threaded
Open this post in threaded view
|

[OT] Re: revision control [was: Re: autoconf and erlang]

Vlad Dumitrescu-4
In reply to this post by Dustin Sallings
Hi,

From: "Dustin Sallings" <dustin>
> I use arch for almost all of my projects.

>From a technical point of view, I guess you are right. I did look at arch and
darcs, but I have a few problems with them: the most important is that arch
isn't available for Windows yet and when it will be, I still have a problem with
command line only tools ;-) Darcs is still beta and last time I checked it
wasn't fully stable (but still usable).

I wouldn't underestimate the power of habit. Arch and darcs have very different
approaches to the "mainstream" CVS setup, so the learning curve is steep. I'd
probably have to be in a particularily good mood to decide to embark on learning
them - especially as (as you say) my needs are simple and don't need the full
power of arch.

As for the distributed repository, that is a big plus for arch/darcs. I'm not
sure how it works in practice, i.e. how do you find the most recent version
among many repositories which aren't all online at the same time, but since the
system is in use, it probably works despite my lack of understanding :-)

Having the repository as a plain directory tree is of no use for me - why should
I ever need to hack it? It could as well be opaque.

>  It's possible to branch a project, track head of line, make
> changes and send them back without even having an internet connection.

Erm, how do you send an email without a connection? ;-)

All in all, in my opinion the big problem is that SourceForge has these
scalability problems and isn't reliable anymore.

regards,
Vlad


Reply | Threaded
Open this post in threaded view
|

[OT] Re: revision control [was: Re: autoconf and erlang]

Dustin Sallings

On May 13, 2004, at 0:10, Vlad Dumitrescu wrote:

> From a technical point of view, I guess you are right. I did look at
> arch and
> darcs, but I have a few problems with them: the most important is that
> arch
> isn't available for Windows yet and when it will be, I still have a
> problem with
> command line only tools ;-) Darcs is still beta and last time I
> checked it
> wasn't fully stable (but still usable).

        GUI tools come.  Some of the developers have what sounds like pretty
decent integration into emacs.  I've got enough integration into vim
for myself.  I use perforce at work and can't begin to comprehend the
GUIs that thing ships with.  The commandline works OK for me, though.  
:)  I do use a web GUI tool, though.

> I wouldn't underestimate the power of habit. Arch and darcs have very
> different
> approaches to the "mainstream" CVS setup, so the learning curve is
> steep. I'd
> probably have to be in a particularily good mood to decide to embark
> on learning
> them - especially as (as you say) my needs are simple and don't need
> the full
> power of arch.

        tla update
        tla commit

        More stuff is there as you need it.

> As for the distributed repository, that is a big plus for arch/darcs.
> I'm not
> sure how it works in practice, i.e. how do you find the most recent
> version
> among many repositories which aren't all online at the same time, but
> since the
> system is in use, it probably works despite my lack of understanding
> :-)

        It sounds like what you're thinking it might be is what I like to call
a ``distributed single point of failure.''  That is to say, multiple
single points which are all required to be available in order for
something to work.  It works quite the other way around.

        There is one ``official'' head of line for tla 1.3.  It is developed
on one of Tom Lord's computers behind his dialup connection to the
internet.  His changes are replicated to at least one mirror very
regularly (I'm not sure how he does it, but I've got a ``hook'' that
mirrors every checkin I do to one machine, and cron jobs that send them
to various other places).  Lots of other people mirror his mirrors and
branch the code on their own trees for their own work.  Those people
make their trees available to others, who perform integration testing,
etc... and then the integration trees get merged back into the head of
line tree and eventually make it into a release.

        The changesets that get merged in contain all of the history
information that made up the change (multiple checkins from various
branches, etc...) and arch is smart enough not to apply the same
changeset twice.

        In this model, everyone who wants to gets a full copy of anyone else's
work which is available when the source is not.

> Having the repository as a plain directory tree is of no use for me -
> why should
> I ever need to hack it? It could as well be opaque.

        It's not so much the ability to hack it, it's more about confidence.  
I am more confident in my ability to back up and restore little files
that each represent a checkin, and that I can read with everyday tools
than a big giant file containing everything that can only be read by
the application that created it.

        It also means you don't need a server of any kind.  tla out of the box
supports any regular filesystem, webdav, sftp, ftp, and plain http
(read-only).

        However, I have hacked some of my repositories in the past.  They're
immutable, so the tools will never update the data, which is a very
good thing, but I wanted to change some info in a tree that I imported
from CVS (a few thousand checkins).  A little python and shell and
all's well.

>>  It's possible to branch a project, track head of line, make
>> changes and send them back without even having an internet connection.
>
> Erm, how do you send an email without a connection? ;-)

        For a long time, I moved email around via UUCP.  In fact, when I first
moved to Silicon Valley (not very long ago), the only ``connectivity''
I had in my hotel room was my nightly UUCP call.  So, sure, there was a
gateway somewhere that had IP, but I didn't have IP to the hotel (now,
between the SGI and the Sun, yeah, but that doesn't count).

> All in all, in my opinion the big problem is that SourceForge has these
> scalability problems and isn't reliable anymore.

        I agree.  It's my opinion that SF is having scalability problems
because it is a popular centralized service.  Unpopular centralized
services and popular decentralized services both hold up fairly well
(although in the unpopular case, people will sometimes turn them off if
they get too unpopular).

        For example, arch is ``hosted'' on Savannah.  When Savannah broke,
most of the services went away.  There were weeks where the mailing
lists weren't even working.  Development continued however.  There was
no central server a developer needed to contact in order to perform a
checkin, or see the latest code.  The only requirement for sharing code
was the ability to get the code to other people (which wasn't a problem
with the number of people mirroring the archives).

        I had projects hosted on sourceforge during a couple of CVS outtages.  
Work simply stopped.  It's rare that I only use one computer during the
day, and I'm generally uncomfortable doing work and not being able to
check it in.  The last time I had any sort of trouble with sourceforge
I took all of my code out of their CVS and stuck it in arch, made a few
mirrors, and never looked back.

--
SPY                      My girlfriend asked me which one I like better.
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________



Reply | Threaded
Open this post in threaded view
|

[OT] Re: revision control [was: Re: autoconf and erlang]

Vlad Dumitrescu-4
From: "Dustin Sallings" <dustin>

Thanks for the nice pro-arch argumentation. For me the real show-stopper is
still that it doesn't work on Windows, the rest are partly old habits and partly
lack of understanding (just reading docs can only get one so far).

> >>  It's possible to branch a project, track head of line, make
> >> changes and send them back without even having an internet connection.
> >
> > Erm, how do you send an email without a connection? ;-)
>
> For a long time, I moved email around via UUCP.

Oh, I see. You meant "_Internet_ connection", but I just saw "connection" and
without a cable going out of your computer and into another, any communication
is quite difficult :-)

regards,
Vlad


Reply | Threaded
Open this post in threaded view
|

[OT] Re: revision control

Luke Gorrie-3
In reply to this post by Vlad Dumitrescu-4
"Vlad Dumitrescu" <vlad_dumitrescu> writes:

> I wouldn't underestimate the power of habit. Arch and darcs have
> very different approaches to the "mainstream" CVS setup, so the
> learning curve is steep. I'd probably have to be in a particularily
> good mood to decide to embark on learning them - especially as (as
> you say) my needs are simple and don't need the full power of arch.

I found the learning curve of Arch pretty steep, but Darcs is a
doddle. One evening is enough to have fun with it -- easier than CVS.

I haven't used any of these systems seriously yet. I just mentioned
Darcs because my first impression is extremely good, and not because
of written-in-functional-language value (I don't particularly care).

It'll take a few years for all these new version control systems to
shake themselves out, and I'm not suggesting we choose a standard.

It is unfortunate that Sourceforge makes the Jungerl hard to work with
though, so I look forward to the world finding consensus on a better
alternative in the future. Hopefully one that's so nice and easy that
even Joe will like it :-)

Cheers,
Luke