Browse thread
[Caml-list] Announcing the OMake build system version 0.9.1
-
Jason Hickey
- Nicolas Cannasse
- Yaron Minsky
- Yamagata Yoriyuki
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2004-09-06 (09:10) |
From: | skaller <skaller@u...> |
Subject: | RE: [Caml-list] Announcing the OMake build system version 0.9.1 |
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