Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Announcing the OMake build system version 0.9.1
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Marcin 'Qrczak' Kowalczyk <qrczak@k...>
Subject: Re: [Caml-list] Announcing the OMake build system version 0.9.1
"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