Longstanding issues: structs & standalone Erlang
Mon Feb 20 12:39:57 CET 2006
> C stuff is what i am discussing. i am trying to say that it
> should _not_ be needed for a ''normal'' erlang
Among the 70 Jungerl libraries, 17 include C code.
Are you trying to say that you don't care for 24% of Erlang
applications? Or is Jungerl not representative of real Erlang
development (i.e. it is not "normal")?
Or do you want to define a simple build system for the simple
cases, and the let the difficult work out of its scope?
> if erlang was used for the install i would not need make, and
> if i did not need make i would not need a c compiler to build
Perhaps we have not been clear.
We do not propose to make every final user type
./configure ; make ; make install to install Erlang apps.
We proposed to offer this as the *common interface* between
developers and packagers, i.e. as a common means to build Erlang
(and other) applications.
I believe that an ambiguity in this thread lies in the confusion
between the roles of developers, packagers and users, who have
different needs and problems.
Fredrik, Vlad, I and others are packagers: we want to provide
installable packages for final users, from applications provided
in source form by developers.
In an ideal world (ideal from a packager's viewpoint), developers
would directly provide packages for final users. But in the real
world packaging requires some work, hence requires packagers in
between developers and users.
You are a final user? Very well, you should not have to deal with
the installation of GNU make or anything like that, and a
packager should have made a package readily usable for you.
More generally, two questions were asked:
1- What common interface should be defined between developers and
Fredrik and I proposed to use Autoconf and make, and you can
discuss it, but please discuss it *as an interface* between
developers and packagers.
We believe that there are not so many packagers out there, and
that a packager (not a final user) can still make the effort to
install GNU make on its own system to package software for
users. No, that's not that difficult...
The problem in choosing another interface between developers and
packagers, e.g. in choosing a build system that downloads code
at build time, is that is would very probably make building
*more difficult* for packaging systems such as Debian or
In practice, such a build configuration would have to be redone
from scratch for packaging: it would be just as if no build
system were provided by the application developers... what a
Therefore, the interface between developers and packagers must be
designed very carefully.
Again, Autoconf and make are the best choice in an Unix world,
and can also easily be used on Windows (Cygwin), but you can
It was also proposed to make every application (including every
OTP app) released separately between developers and packagers,
and (at least) between packagers and end users.
Everybody seems to agree on that point.
2- What could be a packaging system for creating self-installable
self-contained packages for systems that have no packaging
This question is still open, but it is out of question that this
system be Autoconf and make, of course.
But still, we proposed that this packaging system takes source
packages provided by developers, builds them using ./configure ;
make ; make install, and creates self-installable,
self-contained, easy-to-install packages for end-users.
More information about the erlang-questions