[Caml-list] Announcing the OMake build system version 0.9.1

[Caml-list] Announcing the OMake build system version 0.9.1

[Jason Hickey]

OMake is a build system, similar to GNU make, but with many additional
features.  The home site for OMake is http://omake.metaprl.org/

    o Support for large projects spanning several directories or
      directory hierarchies.

    o Builtin support for OCaml and C projects, or a mixture thereof.

    o Fast, accurate, automated dependency analysis using MD5 digests.

    o Portability: omake provides a consistent interface on Win32 and
      on Unix systems including Linux, OSX, and Cygwin.

    o Builtin functions that provide the most common features of programs
      like grep, sed, and awk.  These are especially useful on Win32.

    o Active filesystem monitoring, where the build automatically
      restarts whenever you modify a source file.  This can be
      very useful during the edit/compile cycle.

    o A companion command interpreter, osh, that can be used
      interactively.

In the MetaPRL (http://www.metaprl.org) and Mojave
(http://mojave.caltech.edu) projects we develop and maintain several
moderately large systems consisting of a mixture of OCaml, C, and
theorem proving code.  We developed OMake out of the need for a build
system that was simple, flexible, and reliable, especially for large
projects.

OMake preserves the syntax and rule definitions used in Makefiles,
making it easy to port your project to omake.  There is no need to
code in perl (cons), or Python (scons).  However, there are a few
things to keep in mind:

    1. Indentation is significant, but tabs are not required.
    2. The omake language is functional: functions are first-class
       and there are no side-effects apart from I/O.
    3. Scoping is dynamic.

To try it out, run the command "omake --install" in a project directory,
and edit the generated OMakefile.  Often, an OMakefile is as simple as a 
single line

     OCamlProgram(prog, foo bar baz)

which states that the program "prog" is built from the files
foo.ml, bar.ml, and baz.ml.  You may want to choose which compiler is 
used (by default, omake builds native code).  You can use the 
BYTE_ENABLED and NATIVE_ENABLED flags to control this.

     NATIVE_ENABLED = false
     BYTE_ENABLED = true
     OCamlProgram(prog, foo bar baz)

If you have C files (say file1.c file2.c file3.c) in your project, you 
can add them using the StaticCLibrary function.

     StaticCLibrary(libx, file1 file2 file3)
     OCAML_CLIBS = libx
     OCamlProgram(prog, foo bar baz)

If you have other directories in your project, you can include them with 
the directive

     .SUBDIRS: dir...

For further information see the documentation at 
http://omake.metaprl.org/, especially the section on examples.

OMake 0.9.1 is an alpha release.  While we have made an effort to ensure
that it is bug-free, it is possible some functions may not behave as you
would expect.  Please report any comments and/or bugs to the mailing
list omake@metaprl.org

-- 
Jason Hickey                  http://www.cs.caltech.edu/~jyh
Caltech Computer Science      Tel: 626-395-6568 FAX: 626-792-4257

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Nicolas Cannasse]

> OMake is a build system, similar to GNU make, but with many additional
> features.  The home site for OMake is http://omake.metaprl.org/

Interesting !
However, I can't help thinking that I don't write to learn yet another
language for writing my Makefiles... Why not using directly OCaml for
writing Makefiles and exposing all nice OMake features through a library ?
You would benefit of a good tool for error checks which is the Ocaml
compiler.

Other way to ask the question : what features make the OMake language better
than OCaml for writing Makefiles ? Or is it just syntactic sugar ?

Regards,
Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Yaron Minsky]

On Sat, 04 Sep 2004 09:26:59 -0700, Jason Hickey <jyh@cs.caltech.edu> wrote:
> 
>     o Fast, accurate, automated dependency analysis using MD5 digests.
> 

I've been using omake for a while now and it has worked very well for
us.  One nice feature of omake as opposed to ordinary make (not sure
how this compare to scons and other competitors) is that omake takes a
broader view of dependencies, including the rules themselves in the
calculation.  So, for example, when you modify a build command,
everything that was built with that build command is recompiled.

y

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[chris.danx]

Nicolas Cannasse wrote:
>>OMake is a build system, similar to GNU make, but with many additional
>>features.  The home site for OMake is http://omake.metaprl.org/
> 
> 
> Interesting !
> However, I can't help thinking that I don't write to learn yet another
> language for writing my Makefiles... Why not using directly OCaml for
> writing Makefiles and exposing all nice OMake features through a library ?
> You would benefit of a good tool for error checks which is the Ocaml
> compiler.

I've started to use ocamlconf!  That is a nice tool for doing 
'configuration' based builds (./configure && make && make install style 
builds).  You specify what you want to do in OCaml using some libs, run 
ocamlconf which calls the base system and end up with a configure file. 
  That's not the same as `just' using a makefile, but does provide a 
good example of a DSL embedded in OCaml for the purpose of building 
software, and it's done entirely with library based code.

This seems to work well for me, although I've only just started. 
Makefiles became problematic for managing the code (finding libraries, 
including paths, etc) and previous detours into things like 
autoconf/automake were less than encouraging.  Compared to 
autoconf/automake ocamlconf is a dream.  My only concern is compiling on 
Windows, but Cygwin is available here so I'm hoping that's not going to 
be a big problem.

One question that springs to mind is why hasn't anyone made a tool that 
does the build process based on the semantics of Ocaml?  Or have they? 
I used to (and sometimes still do) program in Ada using Gnat and most of 
the compilation can be handled by tools like gnatmake which handles all 
the dependancies.  The Ada language has some specific rules on 
compilation and recompilation.  Perhaps this is the difference?

Of course you had to manage some configuration issues, but for the 
majority of tasks it was possible to use the gnatmake program to manage 
vast portions of the build process and it was great!!!  This is the only 
thing I miss when not developing with Ada compilers and isn't unique to 
ocaml compilers.  Ada developers are spoiled in this regard. :)


Regards,
Chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Matthieu Dubuget]

chris.danx a écrit :
> Nicolas Cannasse wrote:

>> However, I can't help thinking that I don't write to learn yet another
>> language for writing my Makefiles... Why not using directly OCaml for
>> writing Makefiles and exposing all nice OMake features through a 
>> library ?
> One question that springs to mind is why hasn't anyone made a tool that 
> does the build process based on the semantics of Ocaml?  Or have they? 

May be YaM is a first step toward this. YaM was written by Damien Pous:

http://perso.ens-lyon.fr/damien.pous/shared/ocaml/YaM/

I tried it some time ago and found it very interesting, but need to be 
improved (support of different platforms, more targets, etc.). I began 
to study it and had not the time to continue.

Salutations

Matthieu Dubuget

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Nicolas Cannasse]

> One question that springs to mind is why hasn't anyone made a tool that 
> does the build process based on the semantics of Ocaml?  Or have they? 
> I used to (and sometimes still do) program in Ada using Gnat and most of 
> the compilation can be handled by tools like gnatmake which handles all 
> the dependancies.  The Ada language has some specific rules on 
> compilation and recompilation.  Perhaps this is the difference?

Well I think OCamake is doing this : http://tech.motion-twin.com/ocamake
and it works well on all platforms running OCaml.

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[james woodyatt]

everyone—

[I have a question for the community at the end of this message.  If 
you are interested in this general topic, then please consider 
commenting on my question.  Thanks.]

OMake looks good, but it is GPL— which prevents me from using it until 
it is a widely distributed and mature product.  For developers 
interested in a non-GPL (yet still open source) alternative to the 
venerable Unix make(1) tool, I'd like to mention an old Perl project of 
mine: Conjury.

Conjury was written entirely in modular Perl, and one of its 
interesting features is that the entire build system, including the 
implementation of its construction tools, can be distributed within the 
source code tree of the project which uses it.  It depends only on a 
stock installation of the Perl distribution.

Here is the README for the latest version:

	<http://www.cpan.org/modules/by-module/Conjury/conjury-1.004.readme>

The rest of its documentation is bundled internally as Perldoc, and 
there is no online repository for HTML pages for it.  Sorry.  It is 
licensed under the 2-clause BSD license (like all of my code).  And 
while I haven't maintained it in several years, I have been considering 
resurrecting it for use in my forthcoming OCaml Network Application 
Environment (NAE), which I am building out on SF.Net now.  (This is the 
official project name on SourceForge for what I have previously called 
my Pagoda project.  There is already an unrelated Pagoda project on 
SF.Net.)

I looked at cons and gnatmake and jam and lots of other tools back in 
1999 when I wrote Conjury, and I found them all wanting.  I still need 
to write decent support for the OCaml toolchain before Conjury would 
work for me, but at the moment, it's looking like the best alternative 
available for my purposes.

Would there be interest in Perl Conjury as a separate project if it 
supported the OCaml toolchain, or can I safely just bundle it inside 
OCaml NAE and hide it from the user with a shell written in the Unix 
make(1) language?  Would anyone like to comment on that?  Thanks.


-- 
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Perl Conjury (alternative to Unix make)

[james woodyatt]

On 04 Sep 2004, at 18:18, james woodyatt wrote:
> [...] Here is the README for the latest version:
>
> 	<http://www.cpan.org/modules/by-module/Conjury/conjury-1.004.readme>
>
> The rest of its documentation is bundled internally as Perldoc, and 
> there is no online repository for HTML pages for it.  Sorry.  [...]

Holy cats.  Somebody autogenerated HTML man pages and put them on the 
web.

	<http://www.softbrain.co.kr/CPANdoc/Conjury.html>


-- 
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Eray Ozkural]

On Saturday 04 September 2004 21:01, Yaron Minsky wrote:
> On Sat, 04 Sep 2004 09:26:59 -0700, Jason Hickey <jyh@cs.caltech.edu> wrote:
> >     o Fast, accurate, automated dependency analysis using MD5 digests.
>
> I've been using omake for a while now and it has worked very well for
> us.  One nice feature of omake as opposed to ordinary make (not sure
> how this compare to scons and other competitors) is that omake takes a
> broader view of dependencies, including the rules themselves in the
> calculation.  So, for example, when you modify a build command,
> everything that was built with that build command is recompiled.

Very good! I designed and implemented some build-things myself, this is one of 
the must requirements for any automatic dependency checker. It's sort of 
obvious to use MD5 and include rules in the hash, but the really good idea in 
omake is making one batteries-included package that doesn't depend on 
external scripts or anything like that. I believe that approach is much 
better than autotools approach, where everything is a mess. I know it, 
because I built KDE so many times!

I was actually thinking of re-implementing GNU make in ocaml in a similar way, 
this shows that more can be done.

Regards,

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://malfunct.iuma.com
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[David Brown]

On Sat, Sep 04, 2004 at 06:18:58PM -0700, james woodyatt wrote:

> OMake looks good, but it is GPL? which prevents me from using it until 
> it is a widely distributed and mature product.

There isn't any particular reason you couldn't distribute a GPL program
along with a program of another license.  They aren't linked together, and
therefore the licenses don't affect one another.  Your program could even
be a closed-source binary-only program that is distributed along with omake
(but there is less of a need to do so).

Dave

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[james woodyatt]

On 04 Sep 2004, at 19:03, David Brown wrote:
> On Sat, Sep 04, 2004 at 06:18:58PM -0700, james woodyatt wrote:
>
>> OMake looks good, but it is GPL? which prevents me from using it until
>> it is a widely distributed and mature product.
>
> There isn't any particular reason you couldn't distribute a GPL program
> along with a program of another license.  They aren't linked together, 
> and
> therefore the licenses don't affect one another.  Your program could 
> even
> be a closed-source binary-only program that is distributed along with 
> omake
> (but there is less of a need to do so).

No.  If I turn to a construction tool that comprises the functions I 
want in addition to what is available in the POSIX make(1) tool, then I 
will want to construct my project in such a way that establishes a 
linkage between my source code and the construction tool under the 
terms of the GPL.

The GPL prevents me from using OMake for anything other than what I 
already use Make.  That's no good for me.


-- 
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Sun, 2004-09-05 at 05:59, Matthieu Dubuget wrote:
> chris.danx a écrit :
> > Nicolas Cannasse wrote:
> 
> >> However, I can't help thinking that I don't write to learn yet another
> >> language for writing my Makefiles... Why not using directly OCaml for
> >> writing Makefiles and exposing all nice OMake features through a 
> >> library ?

> May be YaM is a first step toward this. YaM was written by Damien Pous:
> 
> http://perso.ens-lyon.fr/damien.pous/shared/ocaml/YaM/

My personal take is: all 'make' based build systems
are fundamentally flawed because they're based on
the wrong concept. 

The basic problem is that make assumes a fixed set
of target outputs and has rules like:

	A depends on B: use P to make A from B

This means you have to know all the outputs,
dependencies, and build rules in advance
which is *never* the case on any realistic system.

The way forward is to rethink the fundamentals.
Interscript works like this:

	if anything changes rebuild

This rule is universal. Rebuild rules are arbitrary
executable code,  the process is terminated by
detecting a fixpoint, which it can do by tracking
all outputs.

The logic here is reversed. You execute a 'rule'
because it is part of an unfixed build
(a process that hasn't converged to a fixpoint)
NOT because you need to satifsy a dependency.

The problems are ones of optimisation, 
not working around the fact 'make'
is both incomplete and unsound. In other words,
we can use mathematics to reason about how
to optimise it, rather than trying to 'improve'
something which is fundamentally broken.
[Adding optimisations to a universal solution
is fundamentally different to extending an
incomplete one]

For Omake -- the 'automatic file system monitoring'
is not merely a 'convenience' to save typing 'omake'.
Rather it should be viewed as *fundamental* change
to the usual build paradigm -- its a step in the right
direction.

It should solve the following equation:

	d.dvi,d.aux = latex d.tex,d.aux,d.dvi

which is necessary to use latex. (The aux file
holds location of labels which are needed to
generate forward references whose size may
change with the location which may change the
locations of labels ..)

In interscript, I use dynamic code generation.
This is very clumbsy -- print out a Python
file then use 'execfile' to execute it.

Some kind of more advanced partial evaluator
is probably the way to go.


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Yamagata Yoriyuki]

From: Jason Hickey <jyh@cs.caltech.edu>
Subject: [Caml-list] Announcing the OMake build system version 0.9.1
Date: Sat, 04 Sep 2004 09:26:59 -0700

>     o Support for large projects spanning several directories or
>       directory hierarchies.
> 
>     o Builtin support for OCaml and C projects, or a mixture thereof.
> 
>     o Fast, accurate, automated dependency analysis using MD5 digests.
> 
>     o Portability: omake provides a consistent interface on Win32 and
>       on Unix systems including Linux, OSX, and Cygwin.
> 
>     o Builtin functions that provide the most common features of programs
>       like grep, sed, and awk.  These are especially useful on Win32.
> 
>     o Active filesystem monitoring, where the build automatically
>       restarts whenever you modify a source file.  This can be
>       very useful during the edit/compile cycle.
> 
>     o A companion command interpreter, osh, that can be used
>       interactively.

Skimming the document, it appears to be possible, but could OMake
build the arbitrary target, not limited to OCaml or C binary?  For
example, I want to convert data in plain text to a fast-loadable
binary format in the installation time.

--
Yamagata Yoriyuki

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Nathaniel Gray]

On Sat, 4 Sep 2004 19:37:22 -0700, james woodyatt <jhw@wetware.com> wrote:
> On 04 Sep 2004, at 19:03, David Brown wrote:
> > On Sat, Sep 04, 2004 at 06:18:58PM -0700, james woodyatt wrote:
> >
> >> OMake looks good, but it is GPL? which prevents me from using it until
> >> it is a widely distributed and mature product.
> >
> > There isn't any particular reason you couldn't distribute a GPL program
> > along with a program of another license.  They aren't linked together,
> > and
> > therefore the licenses don't affect one another.  Your program could
> > even
> > be a closed-source binary-only program that is distributed along with
> > omake
> > (but there is less of a need to do so).
> 
> No.  If I turn to a construction tool that comprises the functions I
> want in addition to what is available in the POSIX make(1) tool, then I
> will want to construct my project in such a way that establishes a
> linkage between my source code and the construction tool under the
> terms of the GPL.

Can you be more specific?  What are the functions you want?  Why would
they require you to link OMake into your final project and distribute
it to your end users?  Assuming your project is not a build tool
itself, why would you want to make it a derived work of a build tool?

> The GPL prevents me from using OMake for anything other than what I
> already use Make.  That's no good for me.

What use do you have in mind?

Cheers,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Yaron Minsky]

On Sun, 05 Sep 2004 15:12:05 +0900 (JST), Yamagata Yoriyuki
<yoriyuki@mbg.ocn.ne.jp> wrote:

> Skimming the document, it appears to be possible, but could OMake
> build the arbitrary target, not limited to OCaml or C binary?  For
> example, I want to convert data in plain text to a fast-loadable
> binary format in the installation time.

Yes, omake is general purpose.   The built in rules are of course for
specific systems, but you can write rules for pretty much anything.

y

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[David Brown]

On Sun, Sep 05, 2004 at 03:20:56PM +1000, skaller wrote:

> The basic problem is that make assumes a fixed set
> of target outputs and has rules like:
> 
> 	A depends on B: use P to make A from B
> 
> This means you have to know all the outputs,
> dependencies, and build rules in advance
> which is *never* the case on any realistic system.

Amen.

I asked a few years back why nobody had developed a tool similar to
'ghc --make' for Haskell or 'gnatmake' for Ada.  The idea is that you give
it the main module, and the tool works out all of the rules in advance.

There are a couple of problems with these systems, especially in regards to
ocaml.  But, I think there are things to learn from them.

  - They tend to be very tied to their specific language.  When source
    files in this language are themselves generated, this either has to be
    encoded in the make tool (yuck), or the make tool wrapped in a
    makefile, which kind of defeats the purpose.

  - Ocaml allows arbitrary code to be executed during module elaboration
    (to borrow an Ada term).  This causes two issues: 1.  elaboration order
    can be significant, and 2.  modules can be required for the system, but
    not be dependent (in a module sense) on the "main" module.  This also
    means that the notion of a main module is less meaningful on ocaml.

It is very convenient to have a tool where the only rule needed is
something like:

   myprog depends on foo.ml and its dependencies.

In fact, if you specify the modules and also that dependencies are tracked,
it solves the second problem above.  Any time order is important, it can be
specified (as well as additional modules), but when a module is required,
any dependencies are checked and will be included before that module in the
named list.

I wrote a tool to do this, but ran into the first problem above.  Perhaps I
should investigate adding this capability to something like omake.

Dave

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Marcin 'Qrczak' Kowalczyk]

skaller <skaller@users.sourceforge.net> writes:

> The basic problem is that make assumes a fixed set
> of target outputs and has rules like:
>
> 	A depends on B: use P to make A from B
>
> This means you have to know all the outputs,
> dependencies, and build rules in advance
> which is *never* the case on any realistic system.
>
> The way forward is to rethink the fundamentals.
> Interscript works like this:
>
> 	if anything changes rebuild

Rebuild what? Everything? It's not an option. When I repeatedly make
a change in one file and try how it works, it would be silly to wait
several minutes for recompilation of everything else.

It would be interesting to invent some alternative paradigm, but I've
never seen one.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Sun, 2004-09-05 at 23:20, David Brown wrote:

> I asked a few years back why nobody had developed a tool similar to
> 'ghc --make' for Haskell or 'gnatmake' for Ada.  

Or just 'flx progname' for Felix, or python progname for Python,
javac for java  .. :)

> The idea is that you give
> it the main module, and the tool works out all of the rules in advance.
> 
> There are a couple of problems with these systems, especially in regards to
> ocaml.  But, I think there are things to learn from them.
> 
>   - They tend to be very tied to their specific language. 

That's hard to avoid when you're basing dependency information
on the language grammar :)

>     When source
>     files in this language are themselves generated, this either has to be
>     encoded in the make tool (yuck), or the make tool wrapped in a
>     makefile, which kind of defeats the purpose.

To remove the 'yuck' requires two things I think:

	(a) the tool and target language are unified
	(b) the language is designed to generate itself

Such systems do exist -- Forth and I guess Lisp fall into
this category.

>   - Ocaml allows arbitrary code to be executed during module elaboration
>     (to borrow an Ada term).  This causes two issues: 1.  elaboration order
>     can be significant, and 2.  modules can be required for the system, but
>     not be dependent (in a module sense) on the "main" module.  This also
>     means that the notion of a main module is less meaningful on ocaml.

I personally think this is, quite simply, a design fault.

There is also a simple, clear and standard kind of solution,
which Python uses -- mandate explicit specification.
Python uses 'import' for this.

Resolving the actual order of initialisation is another
issue :)

> I wrote a tool to do this, but ran into the first problem above.  Perhaps I
> should investigate adding this capability to something like omake.

Well ocamldep already does most of the work -- for Ocaml code.


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[chris.danx]

Marcin 'Qrczak' Kowalczyk wrote:
> skaller <skaller@users.sourceforge.net> writes:
> 
> 
>>The basic problem is that make assumes a fixed set
>>of target outputs and has rules like:
>>
>>	A depends on B: use P to make A from B
>>
>>This means you have to know all the outputs,
>>dependencies, and build rules in advance
>>which is *never* the case on any realistic system.
>>
>>The way forward is to rethink the fundamentals.
>>Interscript works like this:
>>
>>	if anything changes rebuild
> 
> 
> Rebuild what? Everything? It's not an option. When I repeatedly make
> a change in one file and try how it works, it would be silly to wait
> several minutes for recompilation of everything else.

Only what needs to be rebuilt!

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Marcin 'Qrczak' Kowalczyk]

"chris.danx" <chris.danx@ntlworld.com> writes:

>> Rebuild what? Everything? It's not an option. When I repeatedly make
>> a change in one file and try how it works, it would be silly to wait
>> several minutes for recompilation of everything else.
>
> Only what needs to be rebuilt!

But how does it know it? How to specify that in a different way than
for make?

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[chris.danx]

David Brown wrote:
> Amen.
> 
> I asked a few years back why nobody had developed a tool similar to
> 'ghc --make' for Haskell or 'gnatmake' for Ada.  The idea is that you give
> it the main module, and the tool works out all of the rules in advance.
> 
> There are a couple of problems with these systems, especially in regards to
> ocaml.  But, I think there are things to learn from them.
> 
>   - They tend to be very tied to their specific language.  When source
>     files in this language are themselves generated, this either has to be
>     encoded in the make tool (yuck), or the make tool wrapped in a
>     makefile, which kind of defeats the purpose.

I don't understand what you mean by this, but surely having a tool for 
the most common purposes is better than no tool at all.  I also don't 
see how resorting to make defeats the purpose.  I have had to do this 
with gnatmake when making and using libraries.  Gnatmake builds the 
library but the library needs to exist before you can build the rest of 
the program so you need someway to tell it to biuld the lib first. 
Gnatmake doesn't handle that case.


>   - Ocaml allows arbitrary code to be executed during module elaboration
>     (to borrow an Ada term).  This causes two issues: 1.  elaboration order
>     can be significant, and 2.  modules can be required for the system, but
>     not be dependent (in a module sense) on the "main" module.  This also
>     means that the notion of a main module is less meaningful on ocaml.

Ada has the elaboration problem and it is up to the programmer to solve. 
:)  The programmer needs to know the elaboration order they want in 
order to get the program to work.  If there are elaboration issues the 
programmer must solve them themselves unless the tool can sort them out 
for them.  I see no problem with this.

Perhaps I'm missing something, but I don't see the 2nd problem either. 
The main module depends on modules which depend on modules.  When module 
X depended on by module Y depended on by main changes, X is recompiled, 
then Y then main.  All other modules not dependant on X, Y and main are 
unchanged.  "main" depends on modules, but to me those modules do not 
depend on main.


Chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Sun, 2004-09-05 at 23:38, Marcin 'Qrczak' Kowalczyk wrote:
> skaller <skaller@users.sourceforge.net> writes:

> > Interscript works like this:
> >
> > 	if anything changes rebuild
> 
> Rebuild what? Everything? It's not an option. 

Please understand this as a semantic specification.
Rebuild everything means 'make it so the result is as
if you rebuilt everything' -- if you can tell there is
no need to rebuild something of course you don't.

The issue is how you determine what you can elide
from the build.

Interscript currently does do just what I said and it works.
It does some automatic dependency checking for generating
code, to avoid gratuitous processing.

I'm not suggesting to get rid of explicitly stated
dependencies -- I'm saying that they're to be treated
as cuts -- optimisations.

> When I repeatedly make
> a change in one file and try how it works, it would be silly to wait
> several minutes for recompilation of everything else.

Of course but you're missing the point...

> It would be interesting to invent some alternative paradigm, but I've
> never seen one.

Neither have I. What I mean is: make doesn't work, it's
entirely wrong, so it isn't even a candidate for a build
paradigm.

Fixpoint iteration works and is universal.

So really you don't have any choices here -- there is ONLY
one known correct paradigm, fixpoint iteration.

The issue is how to make it efficient without
destroying its correct semantics and universal nature.

I already have some ideas about that: one needs to
build a categorical model of the processing by specifying
some kind of graph -- note the graph allows cycles.

I actually *implemented* quite a lot of this some years
ago using iTcl and Tk. The graph was visual. The build
system was functional with memoisation (fancy
for saying it used time stamped intermediate product files :)

Believe me I needed such a highly advanced tool:
my job was much more complex than most software
projects -- I was writing a book, and that adds
a LOT of additional project viewpoints and targets,
particularly as the whole thing was literate programmed
and well over 3000 pages :)

Trust Knuth -- he gave up book writing and spent
years developing a typesetting and literate programming
system for this reason.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Marcin 'Qrczak' Kowalczyk]

skaller <skaller@users.sourceforge.net> writes:

> The issue is how you determine what you can elide
> from the build.
>
> Interscript currently does do just what I said and it works.

I don't understand. *How* does it know what to rebuild and how?

> Of course but you're missing the point...

Indeed I am. I don't see how do you specify how code should be rebuilt.

> What I mean is: make doesn't work, it's entirely wrong, so it isn't
> even a candidate for a build paradigm.

Make works for me. What method of specifying building instructions do
you propose instead?

> Fixpoint iteration works and is universal.

What does "fixpoint iteration" mean in this concept? What is iterated?

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[chris.danx]

Marcin 'Qrczak' Kowalczyk wrote:
> "chris.danx" <chris.danx@ntlworld.com> writes:
> 
> 
>>>Rebuild what? Everything? It's not an option. When I repeatedly make
>>>a change in one file and try how it works, it would be silly to wait
>>>several minutes for recompilation of everything else.
>>
>>Only what needs to be rebuilt!
> 
> 
> But how does it know it? How to specify that in a different way than
> for make?

Isn't that information encoded in the source files already?  The tool 
extracts this information and uses it in the build process.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Mon, 2004-09-06 at 01:07, chris.danx wrote:
> David Brown wrote:

> >   - They tend to be very tied to their specific language.  When source
> >     files in this language are themselves generated, this either has to be
> >     encoded in the make tool (yuck), or the make tool wrapped in a
> >     makefile, which kind of defeats the purpose.
> 
> I don't understand what you mean by this, but surely having a tool for 
> the most common purposes is better than no tool at all.  

That may be so, but can we do better? I mean, programmers are
always trying to automate things better, that's what our job is.

>  Gnatmake builds the 
> library but the library needs to exist before you can build the rest of 
> the program so you need someway to tell it to biuld the lib first. 

No you don't! You're making an assumption about build processes
that specifying dependencies is fundamental.

But that isn't the case. Here is a perfectly viable build script:

	build program
	build library

You think that will work? It sure does! Here is the driver:

	limit = 10
	run build
	while (--limit && new_outputs != old_outputs)
		run build
	
This isn't efficient but it works *without* specifying
dependencies or the correct build order. 

If you want it to be faster -- specify
the component builds in the right order :)

Point being -- getting the right order is an optimisation.

> Ada has the elaboration problem and it is up to the programmer to solve. 
> :)  The programmer needs to know the elaboration order they want in 
> order to get the program to work.  If there are elaboration issues the 
> programmer must solve them themselves unless the tool can sort them out 
> for them.  I see no problem with this.

The problem is that the current technique for solving the ordering
problem is to compile and link libraries in a particular
order -- in other words, hand write the build script instead
of generating it.

However if the source code contained enough information,
the build scripts could be generated automatically.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[David Brown]

On Mon, Sep 06, 2004 at 12:31:12AM +1000, skaller wrote:

> > I wrote a tool to do this, but ran into the first problem above.  Perhaps I
> > should investigate adding this capability to something like omake.
> 
> Well ocamldep already does most of the work -- for Ocaml code.

camldep does give all of the necessary information (well, it used to).  It
seems to leave out dependencies that it thinks are obvious (foo.ml produces
foo.cmo or foo.cmx).  But, at least it has enough dependency information to
produce build rules.  I haven't seen anything actually use that information
though.

One problem it has is that if it can't find an appropriate file for a
dependency, it leaves it out.

Dave

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[David Brown]

On Mon, Sep 06, 2004 at 01:08:13AM +1000, skaller wrote:

> Fixpoint iteration works and is universal.

It isn't universal, though.  There are pathalogical cases, even with common
tools where it never will stabilize.  It is an exercise in the TeXbook.
There are also some old Ada compilers that wouldn't build without proper
ordering.  Fortunately, with Ada, the order can be determined from the
source.

In fact, other than C, and the few things I mentioned earlier about ocaml,
a possible (and correct) build order can be determined from an analysis of
the source, and an understanding of the languages involved.

I'm not sure if having a specific build order is a bad thing, I just think
make's approach to determine it aren't right.

Dave

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Marcin 'Qrczak' Kowalczyk]

"chris.danx" <chris.danx@ntlworld.com> writes:

>> But how does it know it? How to specify that in a different way than
>> for make?
>
> Isn't that information encoded in the source files already?

It's not encoded in an automatically extractable way. For example a
Perl script in my project includes a statement
   open TABLES, ">char-tables.c";
but I don't expect a build tool to understand Perl and deduce that
this script should be run to remake char-tables.c.

And it will not know that sources in one subdirectory should be
compiled using one compiler (the previous version) and sources in
another using another (bootstrapped version of the same compiler).

And it will not know the language of the sources to infer dependencies
from them.

So, how would I specify how files should be processed?

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Mon, 2004-09-06 at 01:01, Marcin 'Qrczak' Kowalczyk wrote:
> "chris.danx" <chris.danx@ntlworld.com> writes:
> 
> >> Rebuild what? Everything? It's not an option. When I repeatedly make
> >> a change in one file and try how it works, it would be silly to wait
> >> several minutes for recompilation of everything else.
> >
> > Only what needs to be rebuilt!
> 
> But how does it know it? How to specify that in a different way than
> for make?

I could suggest some, but first: you could use the same
way as for make.

However your dependency specification is treated like
an optimisation. So if you say:

	A depends on B

it means 'A depends on B and some other things' rather than
'A depends only on B'.

This allows you to take a random ordering and adjust it
so B comes before A. The more hints you give,
the more efficient the build. But it will (usually)
converge (or fail to converge) independently of the
ordering.

Obviously one would like something less brain dead
than specifying dependencies file by file -- like

	*.c -> *.o

in make. Or perhaps 'ocamldep' for Ocaml :)

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Nicolas Cannasse]

> > > I wrote a tool to do this, but ran into the first problem above.
Perhaps I
> > > should investigate adding this capability to something like omake.
> >
> > Well ocamldep already does most of the work -- for Ocaml code.
>
> camldep does give all of the necessary information (well, it used to).  It
> seems to leave out dependencies that it thinks are obvious (foo.ml
produces
> foo.cmo or foo.cmx).  But, at least it has enough dependency information
to
> produce build rules.  I haven't seen anything actually use that
information
> though.

Ocamake is using ocamldep to build the dependency tree :
http://tech.motion-twin.com/ocamake.
However, two modules can be mutualy recursive from ocamldep point of view
(both ML depending on other MLI), and this is not enough information to know
in which order we need to link the CMO : this even might be impossible to
link in the cases the modules are effectively recursive ! OCamake is doing
some additional heuristics to try to guess which linking order is best.

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Marcin 'Qrczak' Kowalczyk]

skaller <skaller@users.sourceforge.net> writes:

>> But how does it know it? How to specify that in a different way than
>> for make?
>
> I could suggest some, but first: you could use the same
> way as for make.

How does it simplify my life if I have to write the same Makefile as
for make?

> However your dependency specification is treated like
> an optimisation.

It can't be so, because parts of the information about which sources
to compile is encoded *only* in dependencies in a Makefile.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Mon, 2004-09-06 at 01:38, Marcin 'Qrczak' Kowalczyk wrote:
> skaller <skaller@users.sourceforge.net> writes:
> 
> > The issue is how you determine what you can elide
> > from the build.
> >
> > Interscript currently does do just what I said and it works.
> 
> I don't understand. *How* does it know what to rebuild and how?

It executes the build script, which basically is just a Python
program with some library support thrown in.

It is a literate programming tool, which has two commands
of interest here:

	(1) include file
	(2) open output

Function (2) opens output files, and also stores the name
of the file in a persistent repository. I actually
open a temporary file, write it, and the close() function
actually compares the temporary with the pre-existing file,
and overwrites it if they're different.

The include function opens an input, and also keeps track
of the source tree.

together these two functions conspire to determine which
input files generate which outputs.

Now actually, instead of just opening an include file
for input, what really happens is that the system first
checks if the input, or any of its inputs, as determined
by the last run, have changed (by checking time stamps).

If not, the input is simply skipped over.

The whole process is repeated until the output files
are not changed (or a limit is exceeded).

If you try to include a file that is generated,
all is well even if it is generated *after* you
include it. Either the subsequent generation
will change the output or not. If not, there's
no harm including an old copy, and if so,
this will result in our current output being
different and so the whole process will 
repeat.

Whatever you do DO NOT print the time in seconds into
a generated file :)

Now, you may wonder what this has to do with 
building Ocaml programs, C programs, etc.

There are two answers. The first is: the process is
an instance of something more general: as I have
noted interscript sources can contain arbitrary
Python script to generate outputs, so there isn't
anything in the process which is specific 
to a particular compiler or programming language.

What seems to be required is the ability to 
track the output files -- it isn't relevant
how they're constructed.

However to *optimise* the process, you do need to
have more project specific information.

Now I want to give a kind of messy example why
this process is more or less mandatory for bootrapped
systems.

The Felix build first imports configuration information,
and uses it to condition the generated code.
The configuration is defined as an executable Python file.

The configuration file is generated by 'trial and error'
execution of some scripts and C programs, in the autoconf
style. The actual code that runs these programs is a Python
script -- generated from the LP sources of course.

There is also a makefile which hooks a Python script
for doing the main Ocaml building. It is dependent
on the configuration. It is *also* used to 'make'
the configuration.

So, there are quite a few circular dependencies here,
and the client can actually edit the configuration
by hand as well -- and those changes stick, even
across new versions of the system.

The process is bootstrapped with a makefile that
I manually added to the LP sources -- its sure
to be out of date and misconfigured for your system
but that doesn't matter, because it is only used
to launch the bootstrap -- after that a better
one is extracted from the LP sources, and after
making the config an even better one -- eventually
all this stuff converges to a stable configuration.

I don't need a long toolchain to do all this.
One program -- interscript -- does everything
including find your Ocaml installation :)


> > Of course but you're missing the point...
> 
> Indeed I am. I don't see how do you specify how code should be rebuilt.

I specify the rebuild rules (in Python) in a reasonable order
and just execute them.

The rules are no different in principle than make rules,
except that I use a full scale programming language
to write them (and usually just call the system() function).

> What does "fixpoint iteration" mean in this concept? What is iterated?

The build process repeats until the generated outputs
are the same twice in a row. Consider this function:

	build: file_set -> file_set


Which takes all inputs + outputs and generates new outputs.
Then we just apply 'build' repeatedly until it converges
to a fixpoint 'files' specified by the equation:

	files = build (files)

For example you could define 'build' as this:

	for b in *.ml do ocamlc b

and just repeat it until the *.cmo files don't change.
The initial compilation order is probably wrong.
Fixpoint iteration will eventually lead to a correct
ordering -- in fact the algorithm seems equivalent
to a bubble sort: at least on of the ml files
can't depend on anything so it will compile correctly
on the first pass .. next pass things that depend on it
will be ok .. etc.. so eventually all the files
get built -- no matter what the order is.

More generally this will work even with circular
dependencies, provided of course you design the
system so it converges.

As a counter-example: latex doesn't always converge.


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Mon, 2004-09-06 at 01:44, chris.danx wrote:

> > But how does it know it? How to specify that in a different way than
> > for make?
> 
> Isn't that information encoded in the source files already?  The tool 
> extracts this information and uses it in the build process.


Not quite -- the build rules have to be encoded, yes.
However the encoding is as executable code, so whilst
technically you're right it is extracted and 'used'
by the build process, from the client's viewpoint
it is simply executed.

The build tool itself is a small Python script
which calls functions from a Python library,
and the user can enhance the processing in Python
embedded in the source being read --
so the integration is fairly seamless.

Contrast to autoconf, make, cake, imake ... :)
In theory, these tools are also well integrated
by the Unix OS and shell -- but I find Python
script better (Perl would no doubt be good too).

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Mon, 2004-09-06 at 02:10, Marcin 'Qrczak' Kowalczyk wrote:
> "chris.danx" <chris.danx@ntlworld.com> writes:
> 
> >> But how does it know it? How to specify that in a different way than
> >> for make?
> >
> > Isn't that information encoded in the source files already?
> 
> It's not encoded in an automatically extractable way. For example a
> Perl script in my project includes a statement
>    open TABLES, ">char-tables.c";
> but I don't expect a build tool to understand Perl and deduce that
> this script should be run to remake char-tables.c.

Oh yes it does :)

This is exactly what interscript DOES know how to do.
Here is something similar, since I can't read Perl:

@TABLES = ["Hello", "World"]
@h = tangler("char-tables.c")
@select(tangler)
@for i in TABLES: tangle(i)

This actually writes Hello World into the c file, its just
Python with @ at the front so the parser doen't confuse
it with text.

If you change the TABLES, a new c file is created --
and interscript knows about it too (because the tangler
function creates a tracked output sink ..)

The only caveat here is: if you use a foreign script
to write a file, interscript won't know about the file.
If you use embedded Python, it does (provided you use
an appropriate output object).

> And it will not know that sources in one subdirectory should be
> compiled using one compiler (the previous version) and sources in
> another using another (bootstrapped version of the same compiler).

It doesn't have to. It isn't a declarative system.
It doesn't have to know how to compile files in one
directory or the other.. it just executes the build
commands you give it.

> And it will not know the language of the sources to infer dependencies
> from them.

That isn't true either. It actually does know many languages,
and you can plug in another if you want to.

None of the tanglers I wrote actually bother to track
dependencies but you could do it.

The tanglers are mainly used to insert appropriate
#line directives, but they can do other things.
In particular the Perl tangler also understands perldoc,
and the Python tangler can pretty print using coloured
keywords.

The thing is -- you don't need to know the dependencies.
It helps, but it isn't necessary.

> So, how would I specify how files should be processed?

The usual way -- write the commands out.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Mon, 2004-09-06 at 02:09, David Brown wrote:
> On Mon, Sep 06, 2004 at 01:08:13AM +1000, skaller wrote:
> 
> > Fixpoint iteration works and is universal.
> 
> It isn't universal, though.  There are pathalogical cases, even with common
> tools where it never will stabilize. 

I think it is very rare to find a case which would
stabilise with a manual order and not fixpoint iteration.

Clearly, the claim to universality means 'the result
will eventually converge to the same result as a correct
hand crafted solution'.

This claim isn't true. Every mathematician knows
there are functions with local maxima which are
not global maxima, and some algorithms which try
to converge on the maxima will pick the wrong one.

It is also possible to have processes which
are so badly degenerate unless they're started with
a sensible initial condition they just drop dead
immediately and never recover. I know all about this
one, since interscript is itself literate programmed
and used to build itself -- and a few times I got
a degenerate version with a hidden bug, installed
it as the fallback, only to find the bug propagated ..
and I had to manually edit the fallback Python script
and LP sources (in parallel) to get the bootstrap
converging.

So yes, you're right, but in practice this is very rare,
and its unlikely a conventional system would fare any
better.
.
> There are also some old Ada compilers that wouldn't build without proper
> ordering.  Fortunately, with Ada, the order can be determined from the
> source.

I don't understand. If there is an partial order, fixpoint
iteration should find it (eventually). It doesn't matter
if a build fails, as long as at least one extra step
succeeds each pass.

> I'm not sure if having a specific build order is a bad thing, I just think
> make's approach to determine it aren't right.

Of course it isn't a bad thing! The point is to regard
this kind of information as an optimisation. Fast builds
are important.

All real projects also contain test code, documentation,
and all sorts of other stuff much of which is generated,
and some of which is executed. And these relationships
aren't flat either -- sometimes you need to generate
a program to generate a program: in fact Autoconf
is a perfect example of a long (and fragile) toolchain.

The key thing is that the fixpoint just handles the lot
automatically in almost all cases. [This isn't theory,
I've been using it for well over a decade]

In particular, you can certainly make the building of, 
for example, Ocaml codes fast by specifying an order -- 
possibly by executing some tool that generates it.
[For the Felix project I just maintain a list by hand]

However, to do that for every single tiny part
of the system and get it right is probably quite
hard, even harder to maintain, and at worst
Goedel's theorem might intervene and make it 
completely impossible (since you'd have to manage
the code managing the code ...)

I guess the point I want to make here is that
make systems just don't scale in practice,
and that can't be fixed by extensions or new
versions of it because the fault is fundamental
to the concept of specified targets and dependencies.

We need new concepts, and I'm proposing a new
kind of solution: output tracking, convergence
to fixpoints, an executable high power
scripting system, a uniform packaging mechanism,
and dependencies treated as optimisations.

I'm not claiming interscript itself should be used:
just that the ideas be considered as an alternative
to the way make handles things. 

Interscript 1.0a11[123] Process Mon 06 Sep, 2004 04:22:36 (EST)
SKIPPING (files skipped last run, which did not converge)
BUILDNO 298
Unable to load sh tangler for "bagley/run.sh": using data
$Id: flx_maker.ipk,v 1.75 2004/09/02 13:52:14 skaller Exp $
Pass 1 status: <not converged>
  Files    : 277
  New      : 0
  Changed  : 1
  Unchanged: 276

You see it knows what has changed. And that one file
probably has the CVS time stamp in it or something
because this particular process never converges.
But it doesn't matter -- my program still builds :)

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Marcin 'Qrczak' Kowalczyk]

skaller <skaller@users.sourceforge.net> writes:

> together these two functions conspire to determine which
> input files generate which outputs.

So I must either explicitly tell the dependencies, or run a script
which computes them. Same as in make.

Assume that I forget that compilation of a particular file also reads
another included file, i.e. forget one dependency link. Then after
changing the included file, the target will not be rebuilt (I don't
believe that it will, because then all other targets are in the same
situation and everything would be rebuilt, which is impractical).
So *all* dependencies must be specified. Same as in make.

The difference is in that that "changed" is determined by file
contents rather than time stamps, that compilation is repeated until
it stabilizes, and in the language the makefile is written in.

> If you try to include a file that is generated,
> all is well even if it is generated *after* you
> include it.

This implies that a compile error doesn't abort the compilation
(because the error might result from lack of source which will be made
later). So if I made a fatal error in a C header file included in many
C sources, the time to rebuild all of them and detect the error
multiple times will be wasted.

The time to compile good but out of date files is sometimes wasted too.
Imagine 3 modules:
   module A
   module B uses modules A and C
   module C uses module A
where "uses" actually means "reexports at least a part of it, such
that changes in one interface change the other". The modules happen
to be processed in this order. Someone changed module A. Then A is
recompiled; B is recompiled because A changed; C is recompiled because
A changed; B is recompiled *again* because C changed. 'Make' would
know that it makes no sense to compile B before C.

> More generally this will work even with circular
> dependencies, provided of course you design the
> system so it converges.
>
> As a counter-example: latex doesn't always converge.

It's the only counter-example I know.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Mon, 2004-09-06 at 02:21, Marcin 'Qrczak' Kowalczyk wrote:
> skaller <skaller@users.sourceforge.net> writes:
> 
> >> But how does it know it? How to specify that in a different way than
> >> for make?
> >
> > I could suggest some, but first: you could use the same
> > way as for make.
> 
> How does it simplify my life if I have to write the same Makefile as
> for make?

By build rule I mean the thing
in a makefile after the TAB character. 

> > However your dependency specification is treated like
> > an optimisation.
> 
> It can't be so, because parts of the information about which sources
> to compile is encoded *only* in dependencies in a Makefile.

You can just compile the lot.

For Ocaml code I personally use a linear list with my 
own timestamp checking, and when i find a change
everything in the list thereafter is built.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Mon, 2004-09-06 at 04:45, Marcin 'Qrczak' Kowalczyk wrote:
> skaller <skaller@users.sourceforge.net> writes:
> 
> > together these two functions conspire to determine which
> > input files generate which outputs.
> 
> So I must either explicitly tell the dependencies, or run a script
> which computes them. Same as in make.

This is getting too confusing.

For interscript itself, the answer is no: it automatically
extracts all sources no matter what you change.

No dependency information is required, and no targets,
and no makefile.

It does this by fixpoint iteration -- the interscript
program knows nothing about the source you're generating.
It does know (a) the set of LP sources, because you give
it the first one on the command line and it follows includes.

It also knows every file you generated, because you 
called it to open the file and it keeps track.

What I'm suggesting is that this process is quite general.
It isn't restricted to 'extract source from LP source'.
In particular I leverage that in interscript itself,
by allowing the client to generate sources any way
they think fit using embedded Python.

This idea extends to any kind of build processes.
There's no difference in principle between extracting
sources from a tarball, running interscript, or compiling
a C program to an object file.

All such process will build by fixpoint iteration.

Clearly the exact build commands must be given
to build the system -- whether that is done the hard
way or the commands are generated doesn't matter,
since the fixpoint concept can rebuild the command
script just like any other output.

Clearly if you do NOT encode some dependency information,
the process will be inefficient.

If you lie, it may fail. If you provide partial information
it speeds up, the more the better.

> Assume that I forget that compilation of a particular file also reads
> another included file, i.e. forget one dependency link. Then after
> changing the included file, the target will not be rebuilt (I don't
> believe that it will, because then all other targets are in the same
> situation and everything would be rebuilt, which is impractical).
> So *all* dependencies must be specified. Same as in make.

You are missing the idea -- all the things are not only rebuilt
every time (in principle) they're rebuilt AT LEAST TWICE.

There is no way to check convergence in one pass.

So in the first instance the dependency information
is used to optimise the build order. This reduces
the number of passes required.

For example in worst case to build 26 files A-Z,
where each is dependent on the previous one alphabetically,
if the build order is ZY .. CBA then it will take 26
passes to build, and 27 to verify convergence.

That's not 26 compiles, which you think is too slow --
its 26 SQUARED compiles.

If you reorder the list using partial dependency
information, that reduces the number of passes -- NOT
the number of compiles per pass. If you have enough
information to order the compiles ABCDE ... Z then it
takes one pass to build (and one to verify convergence).

Eliminating some of those compiles is a related but
distinct problem. You may well need full dependency
information to eliminate every eliminable compilation.

As mentioned I personally don't bother with that 
in Felix package, I just use a hand coded linear
order (one pass always converges) and check
each object file against its *.ml file -- 
and  then compile everything thereafter -- that
always works (because it accounts for all the
dependencies, since they've already been checked).

This algorithm doesn't do the minimum compiles,
but ocamlopt.opt is so damn fast it just doesn't matter:
in practice it reduces my compile time by 5-10 times
(since most work is on the backend implementation).

So actually -- I'm not using the fixpoint iteration
at all to compile ocaml code. Its main use in my
package is to handle configuration (which can require
three passes since there's stuff that generates stuff
that generates stuff which the first generator needs .. :)

In practice the fixpoint stuff is quite useful:
first I naturally write things in dependency order
anyhow, and secondly all those passes aren't
done every time -- I just run one pass usually.
Remember that the system uses a persistent store,
so that one pass is probably pass 457 or something :)
I try to strike a balance between reasonable build
speed, and reasonable amount of script to specify
the actual build -- that's important for platform
independence and robustness -- remember the key use
of the build process isn't me building the package,
its for my clients to build the package -- and they
really do have to compile everything :)

> > If you try to include a file that is generated,
> > all is well even if it is generated *after* you
> > include it.
> 
> This implies that a compile error doesn't abort the compilation

Yes. More correctly an error in the build process doesn't
stop the build continuing on (in general). If I want this,
I have to actively program it.

> (because the error might result from lack of source which will be made
> later). So if I made a fatal error in a C header file included in many
> C sources, the time to rebuild all of them and detect the error
> multiple times will be wasted.

Yes. As I have said, the fixpoint idea works, but is
not automatically efficient -- you still need to do some
work to make it efficient.

However unlike make, you can do it as your project grows,
and you can use arbitrary executable script.

> 'Make' would
> know that it makes no sense to compile B before C.

Make is brain dead, it only know what you tell it.
It can't compute anything you can't do in Python
in a roughly similar number of lines of code.
The converse is not true -- Python is much more
expressive than make.

In both cases if you want a completely optimal
build order you have to maintain a complete
dependency graph.

> > As a counter-example: latex doesn't always converge.
> 
> It's the only counter-example I know.

You will discover another source of recusive build
dependencies if you try to bootstrap your language --
and especially if you *also* try to write the build
tool that manages that in your language too .. :))

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Aleksey Nogin]

On 04.09.2004 10:42, Nicolas Cannasse wrote:

> Other way to ask the question : what features make the OMake language better
> than OCaml for writing Makefiles ? Or is it just syntactic sugar ?

It's not about language, it's about the features that the build system 
provides. Here is a list of features of omake that I think would be hard 
or impossible to reproduce in a "Makefile generator":

- Omake knows that a single build command can produce more that one 
file! (Think omcamlopt producing both .cmx and .o, or ocamlc on an 
.mli-free .ml producing both .cmo and .cmi). This really simplifies life 
as you do not have to hack around your build system not knowing the 
side-effects of commands you invoke. See also the "Quick example" below.

- Persistent filesystem monitoring (based on FAM) mode - in this mode, 
as soon as one of the source files is changed, the build is process is 
restarted accordingly (whether omake was idle or already building 
something in the project). In my experience this significantly speeds up 
the process of fixing typos, type checking errors, etc.

- As already mentioned by Yaron, the commands for building a file are 
themselves included in the dependency for the file.

- Complete timestamp/MD5sum testing for file modifications. Note that 
once you make the dependency information truly complete (which is the 
goal of omake), then this becomes a must. Often not all changes in a 
dependencies result in the generated file being actually changed. When a 
file stays the same after it is rebuilt, you want to detect this to 
avoid rebuilding too much.

- Being able to specify "dependencies of dependencies". In other words, 
not only you can specify how to scan a file for dependencies (e.g. 
ocamldep, "gcc -MM", etc), but you can also specify what the scanning 
process itself depends on. For example, if you have a custom 
ocamldep-like program, then you can specify that it needs to be built 
before scanning dependencies of certain files and that whenever that 
binary changes, the dependencies of those files need to be recomputed.

- A global view of the whole project (not just per-directory). This not 
only helps in making sure that the dependency graph is as complete as 
possible, but also gives the parallelizer (omake supports the same -j 
option as make) more freedom. Of course, in a "Makefile generator" you 
could try to generate one huge Makefile for a project, but even with 
such a file if you ever end up calling make recursively, it will no 
longer have a complete view of the whole project.

- Quick example: suppose that you have a file "foo.ml" (with no foo.mli) 
and a file "bar.ml" that refers to "Foo" and supposed that you are 
compiling bytecode. The standard ocamldep would generate

foo.cmo: bar.cmo

dependency. Which means that whenever bar.ml changes, foo.cmo (and 
everything that depends on it) will get rebuilt.

In omake's case, our version of ocamldep will generate the "proper"

foo.cmo: bar.cmi

Then, omake's rule for building .cmi specifies that in the absence of an 
.mli file (and when no rule for building such an .mli is present), use 
"ocamlc %.ml" for building the .cmi. Next, omake will check whether .cmi 
have changed (compared to what it was the last time omake compiled it, 
not compared to what it was right before!) and if not (imagine that 
you've change the code in .ml without affecting the signature - bar.cmo 
would change, but bar.cmi would not), then foo.cmo will not get rebuilt.

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin@cs.caltech.edu (office), aleksey@nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Aleksey Nogin]

On 04.09.2004 18:18, james woodyatt wrote:

> OMake looks good, but it is GPL— which prevents me from using it until 
> it is a widely distributed and mature product. 

Could you please explain what kinds of things you might want to do and 
what license(s) would be needed to make it possible? Right now omake 
only contains code written by 3 people (if I am not mistaken), so if 
there is a strong argument for a different license, then we might 
consider it.

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin@cs.caltech.edu (office), aleksey@nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Aleksey Nogin]

On 05.09.2004 05:48, Yaron Minsky wrote:

> On Sun, 05 Sep 2004 15:12:05 +0900 (JST), Yamagata Yoriyuki
> <yoriyuki@mbg.ocn.ne.jp> wrote:
> 
> 
>>Skimming the document, it appears to be possible, but could OMake
>>build the arbitrary target, not limited to OCaml or C binary?  For
>>example, I want to convert data in plain text to a fast-loadable
>>binary format in the installation time.
> 
> 
> Yes, omake is general purpose.   The built in rules are of course for
> specific systems, but you can write rules for pretty much anything.

Also note that in omake's case, builtin rules are just an external omake 
  file, not some "internal" magic. This makes it possible to just take 
some of the internal rules into your own OMakefile and modify them to 
your liking.

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin@cs.caltech.edu (office), aleksey@nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Marcin 'Qrczak' Kowalczyk]

skaller <skaller@users.sourceforge.net> writes:

> For interscript itself, the answer is no: it automatically extracts
> all sources no matter what you change.
>
> No dependency information is required, and no targets,
> and no makefile.

My makefiles generally include the following types of information:

- Rules which tell "how to compile a *.foo file into a *.bar file"
  and compiler options.

- Variable definitions which gather sources from contents of
  directories. It's usually "all files with a particular extension
  from subdirectories, plus some additions which are generated,
  minus some exceptions which are conditionally excluded".

- Rules which tell which sources and commands to use for many-to-one
  targets like programs and libraries, where source names are not
  derived from target names automatically because there are many
  sources.

- Administrative rules for things like "make clean" and "make install".

All this information is essential for building and impossible to infer
automatically from other files. Another build tool can't eliminate the
need of providing that information in some form. It can only provide a
different language for expressing it.

Dependencies between the source of module Foo which uses module Bar,
and the interface of module Bar, are generated automatically by tools
like ocamldep for particular languages.

> It does know (a) the set of LP sources, because you give it the
> first one on the command line and it follows includes.

If a source is missing, how does it know which program to run in order
to create it?

>> Assume that I forget that compilation of a particular file also reads
>> another included file, i.e. forget one dependency link. Then after
>> changing the included file, the target will not be rebuilt (I don't
>> believe that it will, because then all other targets are in the same
>> situation and everything would be rebuilt, which is impractical).
>> So *all* dependencies must be specified. Same as in make.
>
> You are missing the idea -- all the things are not only rebuilt
> every time (in principle) they're rebuilt AT LEAST TWICE.

So it's out for me. My project already takes 7 minutes to build
(90% of the time is gcc, which is slow on generated files having
hundreds of kilobytes). I don't want to turn it into 14 minutes
without a good reason.

And if I make small changes in one file in order to find some bug,
it's essential to recompile only a few relevant files. How does it
know which other files need to be rebuilt if it does not know *all*
dependencies? Rebuilding everything is out of the question. It should
take 7 seconds, not 7 minutes. And it does with make.

I can't say I like make, but any tool which requires to compile some
files twice, or insists on recompiling everything after a local change,
is not a viable alternative.

> As mentioned I personally don't bother with that in Felix package,
> I just use a hand coded linear order (one pass always converges) and
> check each object file against its *.ml file --

The project I have in mind, a compiler of my language Kogut, currently
has 90 modules in its library. I don't even keep the *set* of filenames
in a Makefile, because I would have to change it each time I add or
rename a module. Maintaining a topologically sorted list by hand would
be a nightmare.

It's not written in OCaml, so there are no issues with module order
for linking, but there are issues with slow compilation. So it's
important to compile only what is needed, and to not compile anything
twice.

> You will discover another source of recusive build
> dependencies if you try to bootstrap your language --

It's already self-hosting. The main compiler is written in the
language it compiles.

In order to build it you can either download a smaller package
containing only "real" sources, if you have an earlier version
installed, or download a larger package with pregenerated portable C
files of (a conservative approximation of) the part of the library
used by the compiler and the compiler proper. These C files are used
to bootstrap some working compiler, which is then used instead of the
"previous version".

> and especially if you *also* try to write the build
> tool that manages that in your language too .. :))

This is why I wrote the compiler driver in Perl :-)

It's the program which calls the actual compiler, C compiler,
assembler, assembler mangler (also written in Perl), and linker,
and finds out what options to give to each. It also generates
dependencies for make.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Announcing the OMake build system version 0.9.1

[Brandon J. Van Every]

Marcin 'Qrczak' Kowalczyk wrote:
>
> My makefiles generally include the following types of information:
>
> - Rules which tell "how to compile a *.foo file into a *.bar file"
>   and compiler options.
>
> - Variable definitions which gather sources from contents of
>   directories. It's usually "all files with a particular extension
>   from subdirectories, plus some additions which are generated,
>   minus some exceptions which are conditionally excluded".
>
> - Rules which tell which sources and commands to use for many-to-one
>   targets like programs and libraries, where source names are not
>   derived from target names automatically because there are many
>   sources.
>
> - Administrative rules for things like "make clean" and "make
> install".
>
> All this information is essential for building and impossible to infer
> automatically from other files. Another build tool can't eliminate the
> need of providing that information in some form. It can only provide a
> different language for expressing it.

'Language', by your definition, can include a GUI.  Under Visual Studio
2003, when doing C++ projects, the only one I definitely have to mess
with is 'make install'.  All the other jobs are common enough that I
simply don't have to worry about them.  Of course, I do have to
point-n-click, drag-n-drop to get my source files properly organized.

Of course, VS 2003 isn't pain free.  I do have to know where various
settings are located in the GUI, and it is definitely possible to put
settings in a 'wrong' or 'poorly architected' place.  It took me awhile
to go up this learning curve - but I put far more effort into GNU Make,
GNU Autoconf, and IMake, once upon a time.  It helps that I have a
grungy command line background, that I know this is really all that's
going on under the hood.  I view VS 2003 .sln files as 'just another
kind of Makefile', and they are usually amenable to hand editing.

You might argue that the 'language' is really in the .sln file, as it is
in a Makefile.  Well, the same can be said about Postscript, but end
users rarely manipulate Postscript directly.  They use tools, because
it's too complicated for most users to edit by hand.  So, part of the
dimension of this discussion, which seems to have the quality of "my
build tool is theoretically better than your tool," is how these things
behave as *TOOLS*.

One dimension of tool quality is how many people use the tool.  I hope
someone has some insight into my question about OCaml build tool
critical mass.

> And if I make small changes in one file in order to find some bug,
> it's essential to recompile only a few relevant files. How does it
> know which other files need to be rebuilt if it does not know *all*
> dependencies? Rebuilding everything is out of the question. It should
> take 7 seconds, not 7 minutes. And it does with make.

In 20..30 years, we will be using cheap, massively parallel computers
and exhaustively searching all the available options.  These issues will
go away.  In fact, *lots* of "how do I interface X and Y?" issues will
go away, we'll use brute force to glue all kinds of things together.
Meanwhile, if you've got enough hardware and a maintainable network,
maybe there's some distributed compilation thingamabob available
somewhere.  Of course, some problems are P-complete, but I'd hazard a
guess that trying different permutations in the hope that one is faster
in practice is not one of them.

> I can't say I like make, but any tool which requires to compile some
> files twice, or insists on recompiling everything after a
> local change, is not a viable alternative.

I'm sure there's probably a gradiated range of tradeoffs available for a
tool designer.  For instance, brute force could generate a provisional
dependency graph, then be reused some of the time, if not all of the
time.  That might actually work to speed things up most of the time.


Cheers,                         www.indiegamedesign.com
Brand*n Van Every               S*attle, WA

Praise Be to the caml-list Bayesian filter! It blesseth
my postings, it is evil crap!  evil crap!  Bigarray!
Unboxed overhead group!  Wondering!  chant chant chant...

Is my technical content showing?

// return an array of 100 packed tuples
temps
  int $[tvar0][2*100]; // what the c function needs
  value $[tvar1]; // one int
  value $[tvar2]; // one tuple
  int $[tvar3] // loop control var
oncePre
eachPre
  $[cvar0]=&($[tvar0][0]);
eachPost
  $[lvar0] = alloc(2*100, 0 /*NB: zero-tagged block*/ );
  for(int $[tvar3]=0;$[tvar3]<100;$[tvar3]++) {
    $[tvar2] = alloc_tuple(2);
    $[tvar1] = Val_int($[cvar0][0+2*$[tvar3]]);
    Store_field($[tvar2],0,$[tvar1]);
    $[tvar1] = Val_int($[cvar0][1]);
    Store_field($[tvar2],1,$[tvar1+2*$[tvar3]]);
    Array_store($[lvar0],$[tvar3],$[tvar0]);
  }
oncePost

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Olivier Grisel]

[-- Attachment #1: Type: text/plain, Size: 122 bytes --]

OMake looks really interesting according to your description. Do you 
plan to provide a GODI package ?

Best,

--
Olivier

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[james woodyatt]

On 05 Sep 2004, at 13:38, Aleksey Nogin wrote:
> On 04.09.2004 18:18, james woodyatt wrote:
>>
>> OMake looks good, but it is GPL— which prevents me from using it 
>> until it is a widely distributed and mature product.
>
> Could you please explain what kinds of things you might want to do and 
> what license(s) would be needed to make it possible?

I want to be able to extend the functions so that my build system knows 
how to use more toolchains than just C and Ocaml, and I want those 
extensions to be bundled with my non-GPL code.  If I were to use Omake, 
then I expect my code would link to the functions in the Omake 
distribution, and I would then be in violation of the GPL if I didn't 
use a GPL-compatible license for my distribution.

> Right now omake only contains code written by 3 people (if I am not 
> mistaken), so if there is a strong argument for a different license, 
> then we might consider it.

I think LGPL might be a more appropriate license for you if you are 
interested in broadening the user base for Omake beyond the GPL 
cybersphere.

I'm not trying to argue for you to change the license.  I am not nearly 
enough of an egomaniac to believe that my declining to use your tool 
should be considered a "strong argument" for you to adopt a different 
license.


-- 
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Aleksey Nogin]

On 05.09.2004 15:57, Olivier Grisel wrote:

> OMake looks really interesting according to your description. Do you 
> plan to provide a GODI package ?

We will probably try providing it if somebody requests it. Currently we 
provide Red Hat RPM packages (source and binaries for various releases 
of Red Hat Linux and Fedora Core) as well as zip files with sources and 
Windows binaries. See http://omake.metaprl.org/download.html

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin@cs.caltech.edu (office), aleksey@nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[chris.danx]

skaller wrote:
> On Mon, 2004-09-06 at 01:07, chris.danx wrote:
> 
>>I don't understand what you mean by this, but surely having a tool for 
>>the most common purposes is better than no tool at all.  
> 
> 
> That may be so, but can we do better? I mean, programmers are
> always trying to automate things better, that's what our job is.

Sometimes we do go to far, witness M$. :)

Just a joke, please don't start a war over this little comment.

> 
>> Gnatmake builds the 
>>library but the library needs to exist before you can build the rest of 
>>the program so you need someway to tell it to biuld the lib first. 
> 
> 
> No you don't! You're making an assumption about build processes
> that specifying dependencies is fundamental.

Yes, you're right.  You don't need to make this assumption but you do 
need to specify what goes in the library and what does not.


> But that isn't the case. Here is a perfectly viable build script:
> 
> 	build program
> 	build library
> 
> You think that will work? It sure does! Here is the driver:
> 
> 	limit = 10
> 	run build
> 	while (--limit && new_outputs != old_outputs)
> 		run build
> 	
> This isn't efficient but it works *without* specifying
> dependencies or the correct build order. 

You didn't specify the dependancies in the "build" system, but you did 
in the files being compiled to some extent.  Are you considering a 
language aware or language neutral solution?


> If you want it to be faster -- specify
> the component builds in the right order :)
> 
> Point being -- getting the right order is an optimisation.
> 
> 
>>Ada has the elaboration problem and it is up to the programmer to solve. 
>>:)  The programmer needs to know the elaboration order they want in 
>>order to get the program to work.  If there are elaboration issues the 
>>programmer must solve them themselves unless the tool can sort them out 
>>for them.  I see no problem with this.
> 
> 
> The problem is that the current technique for solving the ordering
> problem is to compile and link libraries in a particular
> order -- in other words, hand write the build script instead
> of generating it.

Yes this happens in Ada, but it is part of the Ada code (Ada elaboration 
is more complex).  Putting Ada aside, I see no reason to do this in most 
cases for Ocaml though I am no expert.


> However if the source code contained enough information,
> the build scripts could be generated automatically.

**That is what I want to happen**

with the slight change that the program builds the actual program, 
library, whatever.  For the cases the tool is not designed for we can 
rely on ocamlc/ocamlopt and the tools' semantics to cover it ourselves 
if need be.  Ideally developers would not have to deal with that case 
but I'm not sure you can guarantee that when you're interfacing to other 
languages, etc.


Chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Omake] Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Aleksey Nogin]

On 05.09.2004 17:12, james woodyatt wrote:

> I want to be able to extend the functions so that my build system knows 
> how to use more toolchains than just C and Ocaml, and I want those 
> extensions to be bundled with my non-GPL code.  If I were to use Omake, 
> then I expect my code would link to the functions in the Omake 
> distribution, and I would then be in violation of the GPL if I didn't 
> use a GPL-compatible license for my distribution.

There is no "linking" involved when you use the built-in rules of omake. 
The way it looks is that in your own OMakeroot file you will have 
something like:

#
# Include the standard configuration
#
include $(STDROOT)

(although I do not really know what would be considered "linking" in a 
case of an interpreted language).

As I mentioned in an earlier post, the "built-in" support of C, OCaml, 
LaTeX, etc is not some built-in magic - there is just a "global" omake 
file that is included in the distribution that defines a number of 
default rules, using the same syntax that you would use in your own 
OMakefile.

The situation is identical to having a big make file with a lot of 
useful rules and you just adding
include /usr/local/lib/make/UsefulMakeFile
to the Makefile in your project. Doing something like that would in no 
way require modifying make itself in any way.

I would guess there would be nothing wrong with using a liberal license 
(BSD or like) on this "global omake file", in order to allow users to 
borrow pieces of it and freely modify them as needed, while the main 
omake engine would still stay GPL... Do people feel that a license 
change of this sort would be helpful?

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin@cs.caltech.edu (office), aleksey@nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Richard Jones]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

On Sun, Sep 05, 2004 at 03:20:56PM +1000, skaller wrote:
> My personal take is: all 'make' based build systems
> are fundamentally flawed because they're based on
> the wrong concept. 

Can I stand up for 'make' (well, GNU make anyway) and point out
that whatever its philosophical problems, it:

(a) works
(b) works on lots of different platforms, including Windows
(c) works with lots of different languages (except Java, but that's
    Java's fault), including our favorite OCaml, and
(d) is familiar and simple to use for most developers

Sorry, just had to point out that sometimes the perfect tool fails for
practical reasons.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
C2LIB is a library of basic Perl/STL-like types for C. Vectors, hashes,
trees, string funcs, pool allocator: http://www.annexia.org/freeware/c2lib/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: [Caml-list] Announcing the OMake build system version 0.9.1

[Brandon J. Van Every]

james woodyatt wrote:
>
> I'm not trying to argue for you to change the license.  I am
> not nearly
> enough of an egomaniac to believe that my declining to use your tool
> should be considered a "strong argument" for you to adopt a different
> license.

But what other argument could ever be made?  "Strength" of argument is
subjective for all parties, but the argument is inevitably stated in
terms of other people's needs and desires.  A dealbreaker is a
dealbreaker.

LGPL is more permissive than GPL, that much is clear.  It's all a
question of how much restriction you think is necessary for open source
to function in the manner you want.  I think the LGPL is more appealing
to people who think that some restrictions on commerce are a good idea,
but are more interested in commercial recombinative utility than FSF
ideology.

I would note that GNU Make is GPLed and the vast majority of people just
use it, warts and all.  People with special anti-GPL build needs are a
special case.  Such people may create better build methodologies for us
someday, but in the present, GPLing a tool is not a barrier for the vast
majority of build tasks.

One of the few areas where I feel a GPL is acceptable and valid is for a
tool that's particularly cut-and-dried.  Why should I care if my paint
program is GPLed, for instance?  I just want to paint.  I'm not looking
for starter code for a commercial paint program.  Ironically, the GPL
defeats my freedom to recombine such code as I wish... the very thing
the GPL purports to protect!  But if I actually don't care about that
freedom, if I just want to use the tool rather than write a new tool,
GPL is fine.  Maybe I'd fix a bug because it's open source, but
otherwise, why do I care?

The only true freedom is putting the code in the public domain.  MIT/BSD
licenses are pretty darned close to that freedom.  The GPL is not a
'total freedom' license, but rather an 'anti-proprietary' license.  The
GPL philosophy is that proprietary code is Bad [TM].

Waiting for the flames to ensue, for having dared to discuss licenses,
even and despite having made points for all of the main open source
licenses.  Please, do flame away for adding an off-topic licensing
discussion to an already painfully long thread.  I'm sooooooo waiting to
hear how I'm the purveyor of Noise Pollution, in the AC/DC sense.  ;-)


Cheers,                         www.indiegamedesign.com
Brand*n Van Every               S*attle, WA

Praise Be to the caml-list Bayesian filter! It blesseth
my postings, it is evil crap!  evil crap!  Bigarray!
Unboxed overhead group!  Wondering!  chant chant chant...

Is my technical content showing?

// return an array of 100 packed tuples
temps
  int $[tvar0][2*100]; // what the c function needs
  value $[tvar1]; // one int
  value $[tvar2]; // one tuple
  int $[tvar3] // loop control var
oncePre
eachPre
  $[cvar0]=&($[tvar0][0]);
eachPost
  $[lvar0] = alloc(2*100, 0 /*NB: zero-tagged block*/ );
  for(int $[tvar3]=0;$[tvar3]<100;$[tvar3]++) {
    $[tvar2] = alloc_tuple(2);
    $[tvar1] = Val_int($[cvar0][0+2*$[tvar3]]);
    Store_field($[tvar2],0,$[tvar1]);
    $[tvar1] = Val_int($[cvar0][1]);
    Store_field($[tvar2],1,$[tvar1+2*$[tvar3]]);
    Array_store($[lvar0],$[tvar3],$[tvar0]);
  }
oncePost

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Announcing the OMake build system version 0.9.1

[Brandon J. Van Every]

Richard Jones wrote:
>
> Can I stand up for 'make' (well, GNU make anyway) and point out
> that whatever its philosophical problems, it:
>
> (a) works

As per discussion, YMMV.

> (b) works on lots of different platforms, including Windows

Um, sorta.  Getting a GNU Make that is bug-free, up-to-date, and plays
well with MSVC is more problematic than you'd think.  Well at least, I
ran around and around in circles about it for awhile.  Somewhere somehow
I came up with a valid one, and I'm not sure where I got it.  There are
some longstanding bugs pertaining to Windows that are still extant in
the GNU source code, that they're not resolving "because it's not enough
to make another release out of."  This has been true for a few years.
Other people have made patches, but these don't get incorporated into
canonical builds and aren't readily distributed anywhere.

It is more accurate to say that GNU Make works fine in a Cygwin / Mingw
environment.  That isn't really Windows, it's UNIX viralling into
Windows.

Many projects also orient themselves towards GNU Autoconf, which again
is problematic in a pure MSVC environment.  One of these days I may port
Autoconf to MSVC, or track down someone else's effort.  Last time I
looked at that problem, I failed to get it done.  It didn't look like
such an easy problem, because m4 wasn't so easy to move over.  But,
solving *that* problem would be preferrable to going through the same
UNIX dependency-and-elimination headaches one has to do anytime one
moves a project from Cygwin / Mingw to MSVC.  At least if Autoconf
worked in the pure MSVC enviornment and targetted the right header
files, you'd know how much of the Cygwin / Mingw project isn't portable.
Then you could decide if it's trivial to eliminate UNIX dependencies, a
lot of work, or impossible.

So if someone came up with an OCaml-centric build tool that resolved
configuration dependencies, was written in OCaml, worked well under all
platforms including *native* Windows, and lotsa people used it, I'd be
DAMN HAPPY.

I think the Python community is strengthened in this regard.  Seemingly
they can run their stuff on all the platforms, they really don't have to
care much at all which platform it's on.  Getting OCaml to the point
where it's really platform neutral is a worthy goal.  I don't see GNU
Make as part of that goal.  I see it as a stepping stone that many of us
would like to step over already, for all of our various reasons.

> (c) works with lots of different languages (except Java, but that's
>     Java's fault), including our favorite OCaml, and

Agreed.

> (d) is familiar and simple to use for most developers

Gimme a break.  I put a *HUGE* learning curve into GNU Make, once upon a
time.  It's not simple, it's just familiar to a lot of UNIXen.  Ok, it's
simple for trivially sized projects.  When you start getting into
multiple directories, auto-generating dependencies, and keeping debug
vs. release builds separated from one another, you end up doing tons of
manual labor that IDEs like Visual Studio simply solve.

> Sorry, just had to point out that sometimes the perfect tool fails for
> practical reasons.

Yes, again see my question on critical mass.


Cheers,                         www.indiegamedesign.com
Brand*n Van Every               S*attle, WA

Praise Be to the caml-list Bayesian filter! It blesseth
my postings, it is evil crap!  evil crap!  Bigarray!
Unboxed overhead group!  Wondering!  chant chant chant...

Is my technical content showing?

// return an array of 100 packed tuples
temps
  int $[tvar0][2*100]; // what the c function needs
  value $[tvar1]; // one int
  value $[tvar2]; // one tuple
  int $[tvar3] // loop control var
oncePre
eachPre
  $[cvar0]=&($[tvar0][0]);
eachPost
  $[lvar0] = alloc(2*100, 0 /*NB: zero-tagged block*/ );
  for(int $[tvar3]=0;$[tvar3]<100;$[tvar3]++) {
    $[tvar2] = alloc_tuple(2);
    $[tvar1] = Val_int($[cvar0][0+2*$[tvar3]]);
    Store_field($[tvar2],0,$[tvar1]);
    $[tvar1] = Val_int($[cvar0][1]);
    Store_field($[tvar2],1,$[tvar1+2*$[tvar3]]);
    Array_store($[lvar0],$[tvar3],$[tvar0]);
  }
oncePost

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Jacques GARRIGUE]

From: james woodyatt <jhw@wetware.com>
> On 05 Sep 2004, at 13:38, Aleksey Nogin wrote:
> > On 04.09.2004 18:18, james woodyatt wrote:
> >>
> >> OMake looks good, but it is GPL which prevents me from using it 
> >> until it is a widely distributed and mature product.
> >
> > Could you please explain what kinds of things you might want to do and 
> > what license(s) would be needed to make it possible?
> 
> I want to be able to extend the functions so that my build system knows 
> how to use more toolchains than just C and Ocaml, and I want those 
> extensions to be bundled with my non-GPL code.  If I were to use Omake, 
> then I expect my code would link to the functions in the Omake 
> distribution, and I would then be in violation of the GPL if I didn't 
> use a GPL-compatible license for my distribution.

Looks like you make the classical confusion:
1) You have every right to use several (even incompatible) licenses in
   the same distribution (ocaml does it). The only restriction is that
   all code linked inside a GPLed tool must be provided under a
   GPL-compatible license.
2) For code you wrote yourself, you are also free to distribute it
   under several (even incompatible) licenses. So you can reuse your
   extension code in another project (I don't know exactly how if this
   code was intended for omake, but you can), without caring about the
   GPL.

So I don't see how the fact a tool is distributed under the GPL could
limit your ability to use it (and improve it).
The only problem you might have is if you want to link omake itself
with an existing library, and you cannot/would not provide it under a
GPL-compatible license. But I don't see what kind library it would be.

Jacques Garrigue

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Omake] Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Brian Hurt]

On Sun, 5 Sep 2004, Aleksey Nogin wrote:

> On 05.09.2004 17:12, james woodyatt wrote:
> 
> > I want to be able to extend the functions so that my build system knows 
> > how to use more toolchains than just C and Ocaml, and I want those 
> > extensions to be bundled with my non-GPL code.  If I were to use Omake, 
> > then I expect my code would link to the functions in the Omake 
> > distribution, and I would then be in violation of the GPL if I didn't 
> > use a GPL-compatible license for my distribution.
> 
> There is no "linking" involved when you use the built-in rules of omake. 
> The way it looks is that in your own OMakeroot file you will have 
> something like:
> 
> #
> # Include the standard configuration
> #
> include $(STDROOT)
> 
> (although I do not really know what would be considered "linking" in a 
> case of an interpreted language).

Having actually had a discussion with an IP lawyer over basically this 
issue, fears of the GPL in this case are (I think) unfounded.

First off, the GPL only covers, can only cover, derived works.  The GPL-
nor any copyright license- can not "infect" anything other than derived
works.  No license can- as a copyright holder, you only have rights over
the original work and derivitive works, you have no more rights than that,
period.  So the question becomes one of what is a derived work.  Wether or
not simply *linking* creates a derived work is one that has not been
answered authoritively.  Simply manipulating a work, the original work
being manipulated is the work the result is derived from, not the
manipulator.

Simply because you write a document in Microsoft Word doesn't give 
Microsoft copyright to your document.  Simply because you compile code 
with Microsoft compilers, and run them on Microsoft run times, doesn't 
give Microsoft any rights to your code.  The "transformations" don't 
matter, the original work is where the copyright springs from.  Likewise, 
compiling your code with the GPL'd Gnu C does not mean- can not mean- that 
your code has to be GPL.  THe license on the compiler is irrelevent- you 
own both the original work (the code) and the derivitive work (the 
executable).

And simply because your interpreted code gets run on a GPL'd interpreter
doesn't mean your code has to be GPL'd.

Note that the fact that there is only one place that the work "makes
sense" is irrelevent.  I.e. it doesn't matter if the script you wrote only
makes sense as an Omake build script.  In fact, what you wrote doesn't
have to make sense at all, anywhere, anytime- you still own the copyright
to it.  You wrote it, not "deriving" it from any other source, you own the 
copyright.  This is why it's an open question as to wether simply linking 
code makes the linked code "derivitive" enough for the GPL to cross the 
threshold.  If this becomes important, hire a lawyer.

> I would guess there would be nothing wrong with using a liberal license 
> (BSD or like) on this "global omake file", in order to allow users to 
> borrow pieces of it and freely modify them as needed, while the main 
> omake engine would still stay GPL... Do people feel that a license 
> change of this sort would be helpful?
> 

Yes.  On the core interpreter, no.  On the global omake file, yes.  For 
two reasons.  First off, reimplementing someone else's code (even in a 
different language) does create a derivitive work.  Just like translating 
a novel into a different language creates a derivitive work.  Making it a 
BSD license or similiar quashes this concern.  Also, it encourages people 
to grab the file in whole and just edit it, making an obvious derivitive 
work.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Jason Hickey]

>>On 05.09.2004 17:12, james woodyatt wrote:
>>>I want to be able to extend the functions so that my build system knows 
>>>how to use more toolchains than just C and Ocaml, and I want those 
>>>extensions to be bundled with my non-GPL code...

This is sensible, I'd say it is a requirement of a general-purpose build 
system.  We have updated the OMake configuration files to include the 
MIT unrestricted-use license explicitly.

The OMake interpreter remains GPL, which should not affect licensing in 
your project.  The script files use the MIT license, which reads as follows:

---

Permission is hereby granted, free of charge, to any person obtaining a 
copy of this file, to deal in the File without restriction, including 
without limitation the rights to use, copy, modify, merge, publish, 
distribute, sublicense, and/or sell copies of the File, and to permit 
persons to whom the File is furnished to do so, subject to the following 
condition:

THE FILE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
ARISING FROM, OUT OF OR IN CONNECTION WITH THE FILE OR THE USE OR OTHER 
DEALINGS IN THE FILE.

Regards,
Jason

-- 
Jason Hickey                  http://www.cs.caltech.edu/~jyh
Caltech Computer Science      Tel: 626-395-6568 FAX: 626-792-4257

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Christian Lindig]

On Sep 5, 2004, at 3:38 PM, Marcin 'Qrczak' Kowalczyk wrote:

> It would be interesting to invent some alternative paradigm, but I've
> never seen one.

Here are the paradigms for build systems that I know:

	Make - uses rules to specify the dependency tree, walks the dependency 
tree, analyzes the file system, and builds files concurrently (hence, 
no planning in advance)

	Vesta - specifies the build procedure in a functional language and 
evaluates the procedure for building. No concept of updating like in 
Make - all builds are complete in concept; efficiency comes from 
caching intermediate results and hence the evaluator knows that it does 
not have to rebuild everything. The Vesta system observes dependencies 
by observing the tools that are run during the build process: which 
files are read and written. Very powerful but is more an environment 
than a tool.

	Jam - like Make, but has procedural abstraction: a program is 
evaluated to build up the dependency tree. Unlike Make, clean 
separation of phases: analyzes the file system, makes a plan, and 
executes it. Hence, no checking the file system while executing the 
plan. Similar tools: Cons, SCons.

You can find papers here:

http://www.research.compaq.com/SRC/vesta/pubs/pldi-00-04-20.pdf
http://www.dsmit.com/cons/
http://www.perforce.com/jam/jam.html
http://www.perforce.com/jam/jam.html

-- Christian

--
http://www.st.cs.uni-sb.de/~lindig/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Omake] Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Erik de Castro Lopo]

On Sun, 5 Sep 2004 22:54:09 -0500 (CDT)
Brian Hurt <bhurt@spnz.org> wrote:

> Having actually had a discussion with an IP lawyer over basically this 
> issue, fears of the GPL in this case are (I think) unfounded.
> 
> First off, the GPL only covers, can only cover, derived works.  The GPL-
> nor any copyright license- can not "infect" anything other than derived
> works.  No license can- as a copyright holder, you only have rights over
> the original work and derivitive works, you have no more rights than that,
> period.  So the question becomes one of what is a derived work.  Wether or
> not simply *linking* creates a derived work is one that has not been
> answered authoritively. 

I think (and hope) that existing practice supports the idea that
linking does create a derived work.

I am the (sole) author of a library released under dual license;
the GPL for linking with GPL compatibale code and a commercial use
license allowing people to use the library in closed source
applications. This commercial use license earns me money.

The very fact that I give people an option (GPL or commercial)
shows the intention that the library can only be used with 
closed source programs if a license is paid for. I am hoping
that not even the slimiest lawyer would try to get around this.

> This is why it's an open question as to wether simply linking 
> code makes the linked code "derivitive" enough for the GPL to cross the 
> threshold.  If this becomes important, hire a lawyer.

If you do decide to hire a lawyer, be aware of the large body
of existing practice that would be used by the defence to 
uphold the linking/derived work connection.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"Linux is produced to be used, whereas the others are produced
to be sold"  -- Bobby D. Bryant

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Daniel Andor]

On Monday 06 September 2004 1:12 am, james woodyatt wrote:
> On 05 Sep 2004, at 13:38, Aleksey Nogin wrote:
> > Could you please explain what kinds of things you might want to do and
> > what license(s) would be needed to make it possible?
>
> I want to be able to extend the functions so that my build system knows
> how to use more toolchains than just C and Ocaml, and I want those
> extensions to be bundled with my non-GPL code.  If I were to use Omake,
> then I expect my code would link to the functions in the Omake
> distribution, and I would then be in violation of the GPL if I didn't
> use a GPL-compatible license for my distribution.

If you are bundling, not linking, what's wrong with bundling the GPL OMake 
with your non-GPL code, and contributing your OMake improvements back to 
OMake?  

You are perfectly entitled to bundle incompatibly-licensed programs.

If OMake's GPL license somehow compels people to contribute back more 
`toolchain-awareness' and therefore grows the program, then the GPL seems 
like the *ideal* license.  Afterall, it is very unlikely that you will have 
anything of commercial value in the OMake extensions -- would it not be fair 
to say?

D

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[james woodyatt]

On 05 Sep 2004, at 23:39, Jason Hickey wrote:
>
> [...] The script files use the MIT license [...]

Excellent.  That makes me happy happy.  Thank you.


-- 
j h woodyatt <jhw@wetware.com>
that's my village calling... no doubt, they want their idiot back.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Mon, 2004-09-06 at 10:25, chris.danx wrote:

> You didn't specify the dependancies in the "build" system, but you did 
> in the files being compiled to some extent.  Are you considering a 
> language aware or language neutral solution?

Both: in the abstract, the system should be general,
but it needs to be extensible to specialise for cases
where optimisation is desired. Typically people
optimise the 'inner loop' meaning if you spend
much time developing code, you want good performance
compiling things.

If you spend much time running tests, you want 
to optimise that. For Felix, compilation is way
faster than running the regression tests .. so I
actually have optimisation in the form of dependency
checking for the tests (to avoid rerunning slow
tests that already passed).

> > However if the source code contained enough information,
> > the build scripts could be generated automatically.
> 
> **That is what I want to happen**
> 
> with the slight change that the program builds the actual program, 
> library, whatever.  For the cases the tool is not designed for we can 
> rely on ocamlc/ocamlopt and the tools' semantics to cover it ourselves 
> if need be.  Ideally developers would not have to deal with that case 
> but I'm not sure you can guarantee that when you're interfacing to other 
> languages, etc.

Yes. My basic idea is that you need first generalised build
semantics and optimisation model. Then you can tailor it,
without sacrificing generality.

If you start with a broken model like make, you just
can't fix it. 

Make can't even handle trivial requrements such as
unpacking a tarball. What's the target? Heck, you have
to unpack the tarball to find what's in it. Even then,
you have 200 targets, and one process that satisfies
them all -- how do you code that in make?

A typical trick is a dummy target -- GNU itself uses
a file called TIMESTAMP I think, which is just a log
file created as a side-effect of the process to represent
the real set of 'targets'.

Well that doesn't work when you have multiple processes
with the common outputs .. interscript can tangle
code files, or tangle code files AND weave documentation,
so making documentation also makes code -- it would
be silly to 'make code; make doc' since 'make doc'
already satisfies the code target .. ugggg...

G*d help you if you have complex recursive many-to-many
processes -- its easier to just hand code your build
process in some high level language than bother trying
to represent it with make.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Mon, 2004-09-06 at 11:06, Richard Jones wrote:
> On Sun, Sep 05, 2004 at 03:20:56PM +1000, skaller wrote:
> > My personal take is: all 'make' based build systems
> > are fundamentally flawed because they're based on
> > the wrong concept. 
> 
> Can I stand up for 'make' (well, GNU make anyway) and point out
> that whatever its philosophical problems, it:
> 
> (a) works

No it doesn't. That's the problem. If it really did work,
why do imake, omake, ocamake, cake, and many other
such derivates exist?

It fails to be even marginally scalable -- for any significant
project it collapses almost immediately, and these days
it fails -- totally and abysmally -- to cope with 99% of
all C projects as well -- which is why those projects also
use M4, Auto* tools, shell scripts, make templates, Perl
or Python, and many other such tools.

Extend that to a major system requiring multi-platform
support, multiple target kinds (debugging, s
tatic/dynamic link ...) multiple developers, versioning,
documentation and testing, multiple languages,
etc etc and the collapse is total -- the tool becomes
an *impediment* to productivity. Mandating that the
whole of such a control system be written in Perl
plus a small set of external tools is a much better,
more expressive and scalable solution.

I'm not saying make isn't useful, I'm saying it isn't
a general purpose project build tool. It doesn't even
come close.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Mon, 2004-09-06 at 11:50, Brandon J. Van Every wrote:

> Many projects also orient themselves towards GNU Autoconf, which again
> is problematic in a pure MSVC environment. 

Hahahah :) Autoconf doesn't even work on Linux!

> I think the Python community is strengthened in this regard.  Seemingly
> they can run their stuff on all the platforms, they really don't have to
> care much at all which platform it's on.  

Python worked pretty well cross platform, with some care,
for pure Python code for quite some time -- but with distutils
the transparency is enhanced to include C extensions which is a
pretty major leap forward, since extensions are a vital part
of Python.

In fact, Ocaml is pretty close to this goal already: the
lower level technology is largely in place, and tools
like 'findlib' help with integration. There's just no
top level tool, because to make one requires a standard
package architecture (way of installing things so they
get found and built if necessary).

INRIA would probably say "that's not our problem".

> Gimme a break.  I put a *HUGE* learning curve into GNU Make, once upon a
> time.  It's not simple, it's just familiar to a lot of UNIXen.  Ok, it's
> simple for trivially sized projects.  When you start getting into
> multiple directories, auto-generating dependencies, and keeping debug
> vs. release builds separated from one another, you end up doing tons of
> manual labor that IDEs like Visual Studio simply solve.

I doubt IDE's solve this -- they simply provide an interactive
management facility with a higher level of automation, but the price
is that extending them is much harder: they don't scale either,
they just break later :)

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Mon, 2004-09-06 at 12:35, Jacques GARRIGUE wrote:

> Looks like you make the classical confusion:
> 1) You have every right to use several (even incompatible) licenses in
>    the same distribution (ocaml does it). The only restriction is that
>    all code linked inside a GPLed tool must be provided under a
>    GPL-compatible license.

> So I don't see how the fact a tool is distributed under the GPL could
> limit your ability to use it (and improve it).

> The only problem you might have is if you want to link omake itself
> with an existing library,

By resting on unsustainable technical distinctions,
any usage is likely to expose the client to legal risk.

What the heck does 'linkage' actually mean outside
of a Unix based C environment? How is it possible
that you can dlopen an GPL library without infection,
but if you statically link you're infected?

Who says running a mix of programs together
'linked' with shell script isn't linkage?

What about Ocaml code 'linked' by ocamlopt
as opposed to a bytecode version, use of DynLink,
use of top level -- GAK! Its all too confusing
to bother -- especially if you have to explain
it all to your clients as well..


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Omake] Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Mon, 2004-09-06 at 13:54, Brian Hurt wrote:

> THe license on the compiler is irrelevent- you 
> own both the original work (the code) and the derivitive work (the 
> executable).

Except the executable is probably *also* derived from
other header files and libraries.

> If this becomes important, hire a lawyer.

Why would you believe a lawyer who can't cite a long
history of case law (decisions made by judges)?

> First off, reimplementing someone else's code (even in a 
> different language) does create a derivitive work. 

Translating it creates a derived work.  Recoding the
original code creates a derived work. But reimplementing
the same algorithm does not.

So .. hehe .. I could take your module and
copy the mli file and implement the functions and
then the interface is a derived work but the 
implementation is not. And in Ocaml I could then
simply discard the mli file, run ocaml -i
to derive a new mli file -- and hey presto,
now the interface isn't a derived work either ..
even if line for line it is totally identical 
to the original :)

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Andreas Rossberg]

skaller wrote:
>>
>>>Fixpoint iteration works and is universal.
>>
>>It isn't universal, though.  There are pathalogical cases, even with common
>>tools where it never will stabilize. 
> 
> I think it is very rare to find a case which would
> stabilise with a manual order and not fixpoint iteration.

That isn't the point, though. There are tools that are not intended to 
produce stable outputs! For example, a tool might be generating time 
stamps or guids in its output files. Such tools will never work with a 
fixpoint scheme, so you can hardly claim its universality.

Also, I'm not convinced that the move from a declarative to an 
imperative build paradigm is really what most people into functional 
programming would like to see... ;-)

   - Andreas

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

Let's get rid of those possible thingies!  -- TB

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Jacques Garrigue]

From: skaller <skaller@users.sourceforge.net>
> On Mon, 2004-09-06 at 12:35, Jacques GARRIGUE wrote:
> 
> > Looks like you make the classical confusion:
> > 1) You have every right to use several (even incompatible) licenses in
> >    the same distribution (ocaml does it). The only restriction is that
> >    all code linked inside a GPLed tool must be provided under a
> >    GPL-compatible license.
> 
> > So I don't see how the fact a tool is distributed under the GPL could
> > limit your ability to use it (and improve it).
> 
> > The only problem you might have is if you want to link omake itself
> > with an existing library,
> 
> By resting on unsustainable technical distinctions,
> any usage is likely to expose the client to legal risk.
> 
> What the heck does 'linkage' actually mean outside
> of a Unix based C environment? How is it possible
> that you can dlopen an GPL library without infection,
> but if you statically link you're infected?

Please, do not muddy the issue.
We were talking about a standalone tool which is managing compilation
(not even a compiler!)
There is no ambiguity about linkage here, for the good reason that
there is nothing to link to.

Or will you tell me that using gnu make forces me to put all my software
under the GPL!

---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Marcin 'Qrczak' Kowalczyk]

"Brandon J. Van Every" <vanevery@indiegamedesign.com> writes:

> 'Language', by your definition, can include a GUI.  Under Visual Studio
> 2003, when doing C++ projects, the only one I definitely have to mess
> with is 'make install'.  All the other jobs are common enough that I
> simply don't have to worry about them.  Of course, I do have to
> point-n-click, drag-n-drop to get my source files properly organized.

There are two problems with this approach. (Disclaimer: I've never
seen VS.)

1. It relies on the fact that the project is manipulated only within
   VS. You can't just add or rename a file physically, you must
   register it in the project. I guess file metadata are kept with
   explicit lists of files, not with patterns like "all files with
   this extension in all subdirectories of this dir".

   A makefile allows to decouple tools for editing and distribution
   from tools for building. A person working on a project can use any
   editor she wants, even to add and remove files. I already switched
   editors once during this project (from jed to emacs).

   Only some kinds of changes need to be synchronized with makefiles.
   Adding a new "library" to be built currently requires adding it to
   makefiles. Adding a conditionally included module with a few
   alternative implementations too. If there are too many such
   modules, I will do something to automatize it better.

   If some another build tool allowed to manage less metadata
   explicitly, and instead derive them from file contents, it would
   be better. My compiler allows to put various options in parameter
   files stored along with sources, so they don't need to be put in
   makefiles. These parameter files allow to generate the transitive
   closure of "used library" dependencies automatically, and gather
   linker options from them.

2. Integrated environments like VS work better for typical projects.
   They may be hard to adapt to unusual requirements. Consider the
   basic issue of language choice. What one needs to do to use VS with
   a language unknown to VS? How to tell VS about dependencies which
   need to be generated by a custom tool?

   Will it work if the compiler to use on some files is built in
   this very project? How to say that files in this subdirectory
   are usually built with an earlier version of this compiler,
   whose location was determined at some time earlier, but I want
   to explicitly rebuild them with the compiler these files just
   produced?

>> And if I make small changes in one file in order to find some bug,
>> it's essential to recompile only a few relevant files. How does it
>> know which other files need to be rebuilt if it does not know *all*
>> dependencies? Rebuilding everything is out of the question. It should
>> take 7 seconds, not 7 minutes. And it does with make.
>
> In 20..30 years, we will be using cheap, massively parallel computers
> and exhaustively searching all the available options.  These issues will
> go away.

I don't want to wait 20 years. I'm developing the project *now*.

It would already be considered too slow 10 years ago. Unfortunately
my compiler produces big output files which take some time to compile.
This is due to design goals: I wanted it to be fast without the need
of complicated static analysis, and with generating plain portable C.
My way to archieve these goals had a side effect of producing lots
of code.

The resulting executable which does nothing except initializing the
core library has the size of a megabyte (no dynamic linking for now,
except stock C libraries). So it's already heavier than I wished to.
If building was twice as slow, it would be noticeably slower.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Marcin 'Qrczak' Kowalczyk]

Christian Lindig <lindig@cs.uni-sb.de> writes:

> 	Jam - like Make, but has procedural abstraction: a program is
> evaluated to build up the dependency tree. Unlike Make, clean
> separation of phases: analyzes the file system, makes a plan, and
> executes it. Hence, no checking the file system while executing the
> plan. Similar tools: Cons, SCons.

If changes to a module didn't result in changing its interface, my
compiler is careful to not overwrite the interface file, so modules
depending on this module will not be recompiled by make.

How does Jam deal with this? Before we compile a module, we don't know
whether modules which use it will need to be recompiled.

Of course it can conservatively assume that they always will be, but
then it's a disadvantage compared to make.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Olivier Grisel]

[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]

Aleksey Nogin a écrit :
> On 05.09.2004 15:57, Olivier Grisel wrote:
> 
>> OMake looks really interesting according to your description. Do you 
>> plan to provide a GODI package ?
> 
> 
> We will probably try providing it if somebody requests it. 

I think it would make it easier to people distributing their packages 
with godi to have a ready to run omake GODI package. OMake, like any 
other build tool, would be a leaf in the GODI dependency tree and 
therefore providing a GODI package for it would be a first step to 
broaden its adoption among GODI users.

The GODIVA tool can make it really easy to semi-automatically build GODI 
package out of the original tarball (with minor changes).

Furthermore, it seems to me that the omake source tarball at 
http://cvs.metaprl.org:12000/omake/downloads/omake-0.9.1-1.tar.gz has 
been gzipped twice. And I needed to run ./omake before being able to run 
"make install" otherwise I get:
$ ocamlopt.opt -warn-error A -c omake_node.ml
$ omake_magic.cmi is not a compiled interface

Thanks for all,

--
Olivier

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Christian Lindig]

On Sep 6, 2004, at 2:20 PM, Marcin 'Qrczak' Kowalczyk wrote:
> If changes to a module didn't result in changing its interface, my
> compiler is careful to not overwrite the interface file, so modules
> depending on this module will not be recompiled by make.
>
> How does Jam deal with this? Before we compile a module, we don't know
> whether modules which use it will need to be recompiled.

In my understanding, Jam can't deal with this (and hence OCaml). While 
I find a separation of planning and execution highly desirable because 
it enables compilation of build scripts, there must be some kind of 
checking possible while a plan is executed.

-- Christian

--
http://www.st.cs.uni-sb.de/~lindig/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Omake] Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Brian Hurt]

On Mon, 6 Sep 2004, Erik de Castro Lopo wrote:

> I think (and hope) that existing practice supports the idea that
> linking does create a derived work.

What I specifically meant by "not been answered authoritively" is that 
it's never been put in front of a judge.  There is basically no precedent 
to cover this.  While existing practice is helpfull, as it tells the judge 
what is "common sense", it's not as helpfull as precedent is.

Personally, I'm not sure where common sense lies here.  What's the 
definition of derivitive work?  What's the definition of linking?

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Omake] Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Brian Hurt]

On 6 Sep 2004, skaller wrote:

> > If this becomes important, hire a lawyer.
> 
> Why would you believe a lawyer who can't cite a long
> history of case law (decisions made by judges)?

Because they have knowledge and experience that your average programmer or 
blowhard on the internet doesn't have.  I wouldn't trust the average 
lawyer to write code, and I wouldn't trust the average programmer to write 
a license.

> So .. hehe .. I could take your module and
> copy the mli file and implement the functions and
> then the interface is a derived work but the 
> implementation is not. And in Ocaml I could then
> simply discard the mli file, run ocaml -i
> to derive a new mli file -- and hey presto,
> now the interface isn't a derived work either ..
> even if line for line it is totally identical 
> to the original :)

I'm not 100% sure where the line is drawn here.  Nor am I 100% sure anyone 
else is either.

That "blowhard on the internet" quip includes me- IANAL.  An analogy to 
make things clear: I can, with a few sentences, explain type inference to 
my grandmother.  But there are a heck of a lot of intricies and subtlities 
that will get glossed over in this paragraph introduction- some of them 
not so intricate or subtle.  Exactly how corner cases and gray areas get 
handled can not be deduced from this abstract.

In this case, I am grandma- I've had the five minute abstract thrown at 
me over dinner in casual conversation.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Mon, 2004-09-06 at 20:56, Andreas Rossberg wrote:
> skaller wrote:
> >>
> >>>Fixpoint iteration works and is universal.
> >>
> >>It isn't universal, though.  There are pathalogical cases, even with common
> >>tools where it never will stabilize. 
> > 
> > I think it is very rare to find a case which would
> > stabilise with a manual order and not fixpoint iteration.
> 
> That isn't the point, though. There are tools that are not intended to 
> produce stable outputs! For example, a tool might be generating time 
> stamps or guids in its output files. Such tools will never work with a 
> fixpoint scheme, so you can hardly claim its universality.

Yes that's true. So in fact the claim must be watered down.
Perhaps you can help characterize the actual properties
the system has?

One needs to observe that a conventional build will 
also yield indeterminate results, if, for example,
you encode the build time into the result -- build it
again, you get a different timestamp.

Where such artefacts are intended, you can modify the build
specification to exclude this information from consideration
as an output for the purposes of convergence checking.

Interscript can handle this (you can just use 
the ordinary Python open() function instead of the 
special one :)

So yes -- more work is needed to characterize what
can and can't be done, and even more to figure out
how to optimise the process.

> Also, I'm not convinced that the move from a declarative to an 
> imperative build paradigm is really what most people into functional 
> programming would like to see... ;-)

Well, the key concept is of finding a fixpoint,
which is central to functional programming.

The iterative algorithm for doing it is nothing
but tail recursion.. :)

The fact that the build rules are 'executable'
is to obtain generality and is the same as for make.

The thing is that functional programming is NOT declarative.
Perhaps if there were a more universal and efficient
way to specify how to compute a value, there could be,
but so long as one is encoding functions the way
we do in C, C++, Ocaml, and many other similar
languages I can't conceive of it as 'declarative'
programming -- the typing is declarative, and perhaps
Mercury is declarative -- ML function codes certainly
aren't.

I hinted at a way to structure the build rules
more declaratively using a graph generating a category
-- but the fact is I don't really have more than a hint
how this might work.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Mon, 2004-09-06 at 21:34, Jacques Garrigue wrote:
> From: skaller <skaller@users.sourceforge.net>

> Or will you tell me that using gnu make forces me to put all my software
> under the GPL!

I have no idea -- that's the point. My guess is the license
is unenforcible because it depends on terms such as 
'linkage' which can't be well defined in a unique way.

The only way acceptable to a court would be 'community
consensus' about what constitues linkage.

I believe most people believe that
at the moment static linkage to even LGPL (without Ocaml
exemption) infects, but dynamic linkage doesn't.

Given such an absurd distinction I doubt I have any
real idea what the GPL actually says for more
difficult cases.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Christopher A. Watford]

> I have no idea -- that's the point. My guess is the license
> is unenforcible because it depends on terms such as
> 'linkage' which can't be well defined in a unique way.
> 
> The only way acceptable to a court would be 'community
> consensus' about what constitues linkage.
> 
> I believe most people believe that
> at the moment static linkage to even LGPL (without Ocaml
> exemption) infects, but dynamic linkage doesn't.
> 
> Given such an absurd distinction I doubt I have any
> real idea what the GPL actually says for more
> difficult cases.
> 
> --
> John Skaller, mailto:skaller@users.sf.net
> voice: 061-2-9660-0850,
> snail: PO BOX 401 Glebe NSW 2037 Australia
> Checkout the Felix programming language http://felix.sf.net

The whole enforcement of licenses in dynamic linkage would mean that
before using a DLL or SO you'd have to somehow accept an EULA or have
some programatic way of saying your code agrees to their license.
Hell, what about code injection? Would that be illegal if I don't
accept the terms of their license? I'm fairly certain we run into very
murky licensing laws in this regard.

As for what you should do? Static linkage most definately should obey
the license of the library. Dynamic linkage? The end-user has agreed
to follow the library's license/terms, and has pointed an application
to its location. The application shouldn't have to follow any terms,
since its on the insistance of the user (dependency system, physically
downloading it, etc) that the dynamic library be available.

-- 
Christopher A. Watford
christopher.watford@gmail.com
http://dorm.tunkeymicket.com

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Richard Jones]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

On Mon, Sep 06, 2004 at 12:42:28PM -0400, Christopher A. Watford wrote:
> The whole enforcement of licenses in dynamic linkage would mean that
> before using a DLL or SO you'd have to somehow accept an EULA or have
> some programatic way of saying your code agrees to their license.

Not so.

The GPL has nothing to say about using code.  It's all about giving
permission to copy the code.

Since the default case in copyright law is you can't copy the code[1],
you need to get permission if you want to copy, which is what the GPL
grants.

If you don't agree to the GPL, then you revert back to the default
case - ie. you can't copy.

Thus no "EULA" is required.

Anyway, this is extremely off-topic for caml-list.

Rich.

[1] Except under extremely limited cases of fair dealing / fair use,
and possibly being allowed to make a private back-up copy in some
locales.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
NET::FTPSERVER is a full-featured, secure, configurable, database-backed
FTP server written in Perl: http://www.annexia.org/freeware/netftpserver/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Omake] Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Tue, 2004-09-07 at 00:52, Brian Hurt wrote:

> Personally, I'm not sure where common sense lies here.  What's the 
> definition of derivitive work?  

I think there is plenty of precedent for that.

> What's the definition of linking?

But none here.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Godi for OMake [Was: Announcing the OMake build system version 0.9.1]

[Aleksey Nogin]

On 06.09.2004 06:31, Olivier Grisel wrote:

> I think it would make it easier to people distributing their packages 
> with godi to have a ready to run omake GODI package. OMake, like any 
> other build tool, would be a leaf in the GODI dependency tree and 
> therefore providing a GODI package for it would be a first step to 
> broaden its adoption among GODI users.

Well, I have created a godi package for omake that seems to work for me 
(any feedback would be appreciated as I have no previous experience with 
GODI) - http://cvs.metaprl.org:12000/cvsweb/omake/godi-omake/

Now, how do I go about getting it included in the GODI repository? Thank 
you!

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin@cs.caltech.edu (office), aleksey@nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Godi for OMake [Was: Announcing the OMake build system version 0.9.1]

[Olivier Grisel]

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

Aleksey Nogin a écrit :
> On 06.09.2004 06:31, Olivier Grisel wrote:
> 
>> I think it would make it easier to people distributing their packages 
>> with godi to have a ready to run omake GODI package. OMake, like any 
>> other build tool, would be a leaf in the GODI dependency tree and 
>> therefore providing a GODI package for it would be a first step to 
>> broaden its adoption among GODI users.
>
 >
> Well, I have created a godi package for omake that seems to work for me 
> (any feedback would be appreciated as I have no previous experience with 
> GODI) - http://cvs.metaprl.org:12000/cvsweb/omake/godi-omake/

You are fast!

> Now, how do I go about getting it included in the GODI repository? Thank 
> you!

I guess you should contact Gerd to get an account on his repository:
https://gps.dynxs.de/

You might also want to subscribe to the GODI mailing-list:
https://gps.dynxs.de/mailman/listinfo/godi-list

Best,

--
Olivier

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Jacques GARRIGUE]

From: skaller <skaller@users.sourceforge.net>
> On Mon, 2004-09-06 at 21:34, Jacques Garrigue wrote:
> > From: skaller <skaller@users.sourceforge.net>
> 
> > Or will you tell me that using gnu make forces me to put all my software
> > under the GPL!
> 
> I have no idea -- that's the point. My guess is the license
> is unenforcible because it depends on terms such as 
> 'linkage' which can't be well defined in a unique way.
> 
> The only way acceptable to a court would be 'community
> consensus' about what constitues linkage.
> 
> I believe most people believe that
> at the moment static linkage to even LGPL (without Ocaml
> exemption) infects, but dynamic linkage doesn't.
> 
> Given such an absurd distinction I doubt I have any
> real idea what the GPL actually says for more
> difficult cases.

1) this is not a problem of infection, but of right to do something or
   not.
   And the problem with the LGPL is not a problem of linkage (LGPL
   puts no restriction on the linkage itself), but that there are
   conditions in the LGPL which are difficult to fulfill without
   dynamic linking (difficult - not impossible).

2) the point I was trying to make was that the distinction between
   static and dynamic linkage is not relevant here, since the tool 
   discussed does not link to anything anyway.

Or do you just mean that since linkage has not been tested before the
courts, it may mean just anything, including everything present on the
same hard disk?
An ambiguity is only a problem if you happen to be in the ambiguous
area. I do not see how it can matter when you are well outside of it.

(My last answer, this discussion is getting completely ridiculous)

Jacques Garrigue

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller]

On Tue, 2004-09-07 at 12:21, Jacques GARRIGUE wrote:

> 2) the point I was trying to make was that the distinction between
>    static and dynamic linkage is not relevant here, since the tool 
>    discussed does not link to anything anyway.

As it stands. But a client might want to modify it.
They might want to bind more strongly to it.
They might want to add a custom routine to it.

See below for a real example.

> An ambiguity is only a problem if you happen to be in the ambiguous
> area. I do not see how it can matter when you are well outside of it.

Because things change -- what starts off clear may become
less clear as you modify things.

Here is a real example. Felix contains the CIL package,
which is a C parser. It is used in a stand alone wrapper
generator tool. Suppose CIL were GPL***, and I don't care
if the wrapper generator is GPL. All is fine!

Only -- a cute trick is to actually build the wrapper
generator directly into the Felix compiler so you can
#include a C file directly (and the compiler processes
the generated wrappers).

I actually DID do this (although I removed that feature).
Well, if CIL were GPL that would make my core compiler
also GPL -- simply because of a small change in the
integration architecture.

Such absurd artificial constraints in an experimental
package make multi-licence situations undesirable.
It also isn't just a legal problem that I might be
able to sort out -- there is the issue of what
potential clients might think with a cursory
glance at the project.

*** CIL is BSD. If it had been GPL I wouldn't have
even considered it for inclusion.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[Benjamin Geer]

skaller wrote:
> On Tue, 2004-09-07 at 12:21, Jacques GARRIGUE wrote:
>>2) the point I was trying to make was that the distinction between
>>   static and dynamic linkage is not relevant here, since the tool 
>>   discussed does not link to anything anyway.
> As it stands. But a client might want to modify it.
> They might want to bind more strongly to it.
> They might want to add a custom routine to it.

The GPL exists precisely to require people to contribute to free 
software in that particular case.  It is not a criticism of the GPL to 
say that it does its job well.  If you don't wish to abide by the GPL, 
you are of course free not to use GPL'd software.

Ben

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Omake] Re: [Caml-list] Announcing the OMake build system version 0.9.1

[David Brown]

On Sun, Sep 05, 2004 at 10:54:09PM -0500, Brian Hurt wrote:

> Yes.  On the core interpreter, no.  On the global omake file, yes.  For 
> two reasons.  First off, reimplementing someone else's code (even in a 
> different language) does create a derivitive work.  Just like translating 
> a novel into a different language creates a derivitive work.  Making it a 
> BSD license or similiar quashes this concern.  Also, it encourages people 
> to grab the file in whole and just edit it, making an obvious derivitive 
> work.

Although, if it needs to be changed, this should probably be reported as a
bug.  This is important, since this file changes as new versions of omake
come out.

Dave

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Announcing the OMake build system version 0.9.1

[David Brown]

On Tue, Sep 07, 2004 at 02:28:24AM +1000, skaller wrote:

> I believe most people believe that
> at the moment static linkage to even LGPL (without Ocaml
> exemption) infects, but dynamic linkage doesn't.
> 
> Given such an absurd distinction I doubt I have any
> real idea what the GPL actually says for more
> difficult cases.

This distinction is not absurd, at all.  Dynamic linking allows the
recipient of a binary to easily replace the LGPL'd library (which is a
requirement of the LGPL).  With static linking, you have to distribute
objects, or a library consisting of the rest of the program.

I wasn't aware that the GPL allowed dynamic linking.  The only exception
granted is that, since the GPL only covers distribution, the user is free
to dynamic link whatever libraries they wish into the program.  The only
requirement the GPL makes is that these other libraries cannot be required
for normal operation.

But, yes, it starts to get kind of fuzzy when you move away from the C
notion of static and dynamic linking to other systems that differ
conceptually from what was thought of at the time the GPL and LGPL were
written.  Perhaps this is why the GPL-3 has never acheived a fixpoint :-)

Dave

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Godi for OMake [Was: Announcing the OMake build system version 0.9.1]

[Olivier Grisel]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

Aleksey Nogin a écrit :
> On 06.09.2004 13:18, Olivier Grisel wrote:
> 
>> I guess you should contact Gerd to get an account on his repository:
>> https://gps.dynxs.de/
>>
>> You might also want to subscribe to the GODI mailing-list:
>> https://gps.dynxs.de/mailman/listinfo/godi-list
> 
> 
> Thanks, I've added it to the 3.08 version of the GODI repository.
> 
Good news ! I'm currently experimenting with omake for some personal 
project, and it's really a great tool.

It would be even greater if omake and findlib could better interoperate 
especially for installation targets.

Thanks for your work !

-- Olivier

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

[Caml-list] OCamlFind support in OMake [Was: Godi for OMake]

[Aleksey Nogin]

On 24.09.2004 06:50, Olivier Grisel wrote:

> It would be even greater if omake and findlib could better interoperate 
> especially for installation targets.

We already have a patch (contributed by Bardur Arantsson) to add 
ocamlfind support - please see 
http://cvs.metaprl.org:12000/bugzilla/show_bug.cgi?id=304
I expect that some version of the patch will be included in OMake 0.9.3

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin@cs.caltech.edu (office), aleksey@nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners