Hi Reid,> Since there's been little feedback on the design document I sent out, > some decisions are being made in order to progress the work. If you have > strong feelings about any of these, voice them now! > > 1. Name = llvmccI like llvmcc, but really have no strong opinion.> 2. The config file format will resemble Microsoft .ini files > (name=value in sections)I prefer the XML version of the config file format. It's well-formed and there are tools out there that can parse it already. The verbosity of it isn't that much of a concern anymore with modern systems. I think that it will help later on if a configuration tool is created that generates these XML files. This is my 2 sous. -bw -- || "If wishes and buts were clusters of nuts, we'd all have a bowl of || granola!" - Mr. Jellineck
Hi Bill, On Mon, 2004-08-02 at 21:31, Bill Wendling wrote:> Hi Reid, > > > Since there's been little feedback on the design document I sent out, > > some decisions are being made in order to progress the work. If you have > > strong feelings about any of these, voice them now! > > > > 1. Name = llvmcc > > I like llvmcc, but really have no strong opinion.I think we're slowly setting on llvmcs (LLVM Compiler Suite or Compilation System).> > > 2. The config file format will resemble Microsoft .ini files > > (name=value in sections) > > I prefer the XML version of the config file format. It's well-formed and > there are tools out there that can parse it already. The verbosity of it > isn't that much of a concern anymore with modern systems. I think that > it will help later on if a configuration tool is created that generates > these XML files.I tend to agree. I'm a strong advocate of XML myself (on other projects). However, introducing XML would make LLVM dependent on some kind of XML parser. We could probably get away with expat (small, fast) for our purposes in LLVM, but there is still the issue of dependency. To avoid dependency, its possible a simple, recursive descent parser that only understood the LLVM configuration document type could be written. Perhaps others could chime in on this issue. Is the need to keep LLVM independent of other packages that strong? We already depend on GCC and several other tools (bison, flex, doxygen, unix editors, etc.) Is one more a big deal? Reid. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040802/ee875c4f/attachment.sig>
On Mon, 2 Aug 2004, Reid Spencer wrote:> Hi Bill, > On Mon, 2004-08-02 at 21:31, Bill Wendling wrote: > > Hi Reid, > > > > > Since there's been little feedback on the design document I sent out, > > > some decisions are being made in order to progress the work. If you have > > > strong feelings about any of these, voice them now! > > > > > > 1. Name = llvmcc > > > > I like llvmcc, but really have no strong opinion. > > I think we're slowly setting on llvmcs (LLVM Compiler Suite or > Compilation System).aka llvm cool stuff> I tend to agree. I'm a strong advocate of XML myself (on other > projects). However, introducing XML would make LLVM dependent on some > kind of XML parser. We could probably get away with expat (small, fast) > for our purposes in LLVM, but there is still the issue of dependency. ToTo me, it's not a matter of "one more dependency". If it makes sense and buys us something tangible, it would make sense to go with XML. In my mind, for our purposes, if the config file gets complex enough to need tool support like this, we have already failed. -Chris -- http://llvm.cs.uiuc.edu/ http://nondot.org/sabre/