Longstanding issues: structs & standalone Erlang

[Romain Lenglet]

Hi,

[...]
> C stuff is what i am discussing. i am trying to say that it
> should _not_ be needed for a ''normal'' erlang
> application/library.

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

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. 
That's right.


More generally, two questions were asked:

1- What common interface should be defined between developers and 
packagers?

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 
buildit.
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 
waste!
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 
discuss it.

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 
system?

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.


Regards,

-- 
Romain LENGLET