[erlang-questions] Use of makefiles

Bob Ippolito bob@REDACTED
Thu Mar 6 02:02:30 CET 2008


On Wed, Mar 5, 2008 at 2:51 PM, Richard A. O'Keefe <ok@REDACTED> wrote:
>
>  On 5 Mar 2008, at 8:58 pm, Bengt Kleberg wrote:
>  > The question I asked was if a perl program would be more likely to run
>  > on ''any'' machine, than a makefile. Not because the person who wrote
>  > the makefile forgot/failed to read the manual for gnu make, but
>  > because
>  > there are other make programs than gnu make out there. The 4 ones I
>  > have
>  > used where not compatible. They would not run each others makefiles.
>
>  If you stick to what's described in the original Make paper, every
>  Make I
>  have ever come across (save on Windows) is compatible with that.  I try
>  to stick to what's described in the Single Unix Specification, and
>  haven't
>  had any trouble with portability.  I haven't tried nmake on Windows, but
>  GNU make is available for Windows and can handle POSIX (=SUS) makefiles.
>
> >
>  >
>  > I have heard that there is only one perl, so it should be compatible.
>
>  It is not true that there is only one Perl.  There has been one Perl
>  development
>  stream, but there have been many versions issued in that stream.  What
>  works
>  in Perl 5.8.8 might not work in Perl 5.4, and probably won't work in
>  Perl 6 if that
>  ever gets finished.  (You are aware that Perl 6 is supposed to be a
>  whole new
>  language?)
>
> >
>  > So, is the chance of finding perl on ''any'' computer bigger than the
>  > chance of finding the right make program for your makefile?
>
>  I respectfully suggest that there is a bigger problem than makefile
>  compatibility,
>  and that is C compiler command line compatibility.  For example, to
>  get optimised
>  code I write
>         cc -O2 foobar.c
>  on one machine, but
>         cc -xO2 foobar.c
>  on another, and on another machine, sadly decommissioned because the
>  vendor
>  having stopped making the hardware and having decided never to upgrade
>  the
>  compiler or operating system nevertheless decided to start charging a
>  really
>  ridiculous licence fee to run the thing in multiuser mode, the command
>  line switches
>  were different again.  Come to think of it, I have three C compilers
>  on one machine,
>  all with different switches, so simply checking which operating system
>  it is won't help.
>
>  When I use R, all of that is handled for me; if I ask the R system to
>  arrange a C (or
>  Fortran) compilation for me, it remembers what worked when it was
>  built, and does
>  it for me.  Wouldn't it be nice if installing Erlang gave you
>         erl cc ...
>  that would run a C compiler with all the right switches to work with
>  Erlang?

That's what Python does, it saves the Makefile that was generated
during the Python build and its distutils build system will parse out
features from that Makefile in order to build extensions. It doesn't
actually invoke make at any point beyond the initial ./configure; make
of the python system, it's effectively used as a configuration file.

-bob



More information about the erlang-questions mailing list