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 QAA17559; Mon, 23 Sep 2002 16:36:27 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id QAA17348 for ; Mon, 23 Sep 2002 16:36:27 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g8NEaJ528322; Mon, 23 Sep 2002 16:36:19 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA16916; Mon, 23 Sep 2002 16:36:19 +0200 (MET DST) Date: Mon, 23 Sep 2002 16:36:19 +0200 From: Xavier Leroy To: Sven LUTHER Cc: Gerd Stolpmann , Alessandro Baretta , Ocaml Subject: Re: We should start using -pack by default when building libraries, (was : Re: [Caml-list] Meta module in findlib and the need for namespaces) Message-ID: <20020923163619.A16997@pauillac.inria.fr> References: <3D87406D.9010406@baretta.com> <20020922212920.GG914@ice.gerd-stolpmann.de> <20020923084301.GA1272@iliana> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20020923084301.GA1272@iliana>; from luther@dpt-info.u-strasbg.fr on Mon, Sep 23, 2002 at 10:43:01AM +0200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > > Note that dynlink.cma not only contains Meta, but also other modules > > with plain names: Misc, Config, Ident, Path, Types, i.e. names for > > which name clashes are much more likely than for cryptic names. > > Well, is it not for exactly this kind of problems that the -pack option > was implemented ? Yes, exactly. > Would it not solve all this kind of problem if it > would be a standard that all libraries should be using the -pack option > for including their modules, thus having a Dynlink.Meta, Dynlink.Misc, > Dynlink.Config, ... (and also i guess findlib would then have a > Findlib.Meta or something such ?). > Sure this would cause a bit of backward compatibility, but nothing that > could not be solved by a simple open at the begining of the sources, and > it would also most probably help solving much of the 'namespace' > discution that happens here from time to time. In the case of Dynlink, it's even better than this: the Misc, Meta, etc, compiler modules that it imports are used purely internally and need not be re-exported to the user, so we can keep the old API by having just two modules, Dynlink (the user-visible API) and Dynlink_internal_impossibly_long_name (a "pack" of the compiler modules that Dynlink needs). For other existing libraries, backward compatibility can deter using -pack, but I'd encourage authors of new libraries to use it in order to export only one compilation unit. - Xavier Leroy ------------------- 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