From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA09583; Mon, 6 Sep 2004 14:13:21 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA08902 for ; Mon, 6 Sep 2004 14:13:20 +0200 (MET DST) Received: from qrnik.knm.org.pl (paf87.warszawa.sdi.tpnet.pl [217.96.225.87]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i86CDIpx012951 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 6 Sep 2004 14:13:19 +0200 Received: from qrczak by qrnik.knm.org.pl with local (Exim 3.36 #1) id 1C4IMz-0004QA-00; Mon, 06 Sep 2004 14:13:13 +0200 To: "Brandon J. Van Every" Cc: "caml" Subject: Re: [Caml-list] Announcing the OMake build system version 0.9.1 References: From: "Marcin 'Qrczak' Kowalczyk" Mail-Followup-To: "Brandon J. Van Every" , "caml" Date: Mon, 06 Sep 2004 14:13:13 +0200 In-Reply-To: (Brandon J. Van Every's message of "Sun, 5 Sep 2004 15:41:40 -0700") Message-ID: <87vferh9ye.fsf@qrnik.zagroda> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at nez-perce with ID 413C545E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 marcin:01 'qrczak':01 kowalczyk:01 qrczak:01 brandon:99 gui:01 'make:01 install':01 transitive:01 dependencies:01 dependencies:01 subdirectory:01 bug:01 initializing:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk "Brandon J. Van Every" 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