caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl>
To: "Brandon J. Van Every" <vanevery@indiegamedesign.com>
Cc: "caml" <caml-list@inria.fr>
Subject: Re: [Caml-list] Announcing the OMake build system version 0.9.1
Date: Mon, 06 Sep 2004 14:13:13 +0200	[thread overview]
Message-ID: <87vferh9ye.fsf@qrnik.zagroda> (raw)
In-Reply-To: <OOEALCJCKEBJBIJHCNJDOELIHHAB.vanevery@indiegamedesign.com> (Brandon J. Van Every's message of "Sun, 5 Sep 2004 15:41:40 -0700")

"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


  reply	other threads:[~2004-09-06 12:13 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-04 16:26 Jason Hickey
2004-09-04 17:42 ` Nicolas Cannasse
2004-09-04 18:27   ` chris.danx
2004-09-04 19:59     ` Matthieu Dubuget
2004-09-05  5:20       ` skaller
2004-09-05 13:20         ` David Brown
2004-09-05 14:31           ` skaller
2004-09-05 16:02             ` David Brown
2004-09-05 16:14               ` Nicolas Cannasse
2004-09-05 15:07           ` chris.danx
2004-09-05 15:53             ` skaller
2004-09-06  0:25               ` chris.danx
2004-09-06  8:17                 ` skaller
2004-09-05 13:38         ` Marcin 'Qrczak' Kowalczyk
2004-09-05 14:50           ` chris.danx
2004-09-05 15:01             ` Marcin 'Qrczak' Kowalczyk
2004-09-05 15:44               ` chris.danx
2004-09-05 16:10                 ` Marcin 'Qrczak' Kowalczyk
2004-09-05 17:38                   ` skaller
2004-09-05 17:15                 ` skaller
2004-09-05 16:11               ` skaller
2004-09-05 16:21                 ` Marcin 'Qrczak' Kowalczyk
2004-09-05 19:09                   ` skaller
2004-09-05 15:08           ` skaller
2004-09-05 15:38             ` Marcin 'Qrczak' Kowalczyk
2004-09-05 17:04               ` skaller
2004-09-05 18:45                 ` Marcin 'Qrczak' Kowalczyk
2004-09-05 20:12                   ` skaller
2004-09-05 21:30                     ` Marcin 'Qrczak' Kowalczyk
2004-09-05 22:41                       ` Brandon J. Van Every
2004-09-06 12:13                         ` Marcin 'Qrczak' Kowalczyk [this message]
2004-09-05 16:09             ` David Brown
2004-09-05 18:31               ` skaller
2004-09-06 10:56                 ` Andreas Rossberg
2004-09-06 15:51                   ` skaller
2004-09-06  7:11           ` Christian Lindig
2004-09-06 12:20             ` Marcin 'Qrczak' Kowalczyk
2004-09-06 14:12               ` Christian Lindig
2004-09-06  1:06         ` Richard Jones
2004-09-06  1:50           ` Brandon J. Van Every
2004-09-06  9:09             ` skaller
2004-09-06  8:59           ` skaller
2004-09-04 23:58     ` Nicolas Cannasse
2004-09-05  1:18       ` james woodyatt
2004-09-05  1:26         ` [Caml-list] Perl Conjury (alternative to Unix make) james woodyatt
2004-09-05  2:03         ` [Caml-list] Announcing the OMake build system version 0.9.1 David Brown
2004-09-05  2:37           ` james woodyatt
2004-09-05  6:24             ` Nathaniel Gray
2004-09-05 20:38         ` Aleksey Nogin
2004-09-06  0:12           ` james woodyatt
2004-09-06  0:33             ` [Omake] " Aleksey Nogin
2004-09-06  3:54               ` Brian Hurt
2004-09-06  6:39                 ` Jason Hickey
2004-09-06  8:10                   ` james woodyatt
2004-09-06  7:50                 ` [Omake] " Erik de Castro Lopo
2004-09-06 14:52                   ` Brian Hurt
2004-09-06 17:20                     ` skaller
2004-09-06  9:52                 ` skaller
2004-09-06 15:10                   ` Brian Hurt
2004-09-07 13:26                 ` David Brown
2004-09-06  1:14             ` Brandon J. Van Every
2004-09-06  2:35             ` Jacques GARRIGUE
2004-09-06  9:38               ` skaller
2004-09-06 11:34                 ` Jacques Garrigue
2004-09-06 16:28                   ` skaller
2004-09-06 16:42                     ` Christopher A. Watford
2004-09-06 16:59                       ` Richard Jones
2004-09-07  2:21                     ` Jacques GARRIGUE
2004-09-07  6:17                       ` skaller
2004-09-07  8:24                         ` Benjamin Geer
2004-09-07 13:35                     ` David Brown
2004-09-06  7:51             ` Daniel Andor
2004-09-05 20:38   ` Aleksey Nogin
2004-09-05 22:57     ` Olivier Grisel
2004-09-06  0:17       ` Aleksey Nogin
2004-09-06 13:31         ` Olivier Grisel
2004-09-06 19:28           ` [Caml-list] Godi for OMake [Was: Announcing the OMake build system version 0.9.1] Aleksey Nogin
2004-09-06 20:18             ` Olivier Grisel
     [not found]               ` <41537DAE.1050601@cs.caltech.edu>
2004-09-24 13:50                 ` Olivier Grisel
2004-09-24 18:37                   ` [Caml-list] OCamlFind support in OMake [Was: Godi for OMake] Aleksey Nogin
2004-09-04 18:01 ` [Caml-list] Announcing the OMake build system version 0.9.1 Yaron Minsky
2004-09-05  1:38   ` Eray Ozkural
2004-09-05  6:12 ` Yamagata Yoriyuki
2004-09-05 12:48   ` Yaron Minsky
2004-09-05 20:39     ` Aleksey Nogin
2004-09-06 12:24 Jason Smith
2004-09-06 15:54 ` Christopher A. Watford

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87vferh9ye.fsf@qrnik.zagroda \
    --to=qrczak@knm.org.pl \
    --cc=caml-list@inria.fr \
    --cc=vanevery@indiegamedesign.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).