Am 17.02.2013 11:21, schrieb Peter Sommerfeld: > Am 17.02.2013, 10:24 Uhr, schrieb Russel Winder: >> On Sun, 2013-02-17 at 09:12 +0100, Sönke Ludwig wrote: >> >>> I agree about the non-optimal syntax, but it comes down to nicer syntax >>> (where JSON at least is not _too_ bad) vs. standard format (familiarity, >>> data exchange, proven design and implementation). And while data >>> [...] >> >> Peter's point is more important than the above response indicates. > > I think so too. And I don't believe that it will stay by a few lines > only because the demands will increase in the course of time. Think > about including C/C++ compiler, a project manager etc.
If I were to vote for anything, that would be to never support C/C++ or any other foreign language builds. There are enough tools for that and I don't see enough value for the huge complexity that this route would add (just consider autotools or cmake). Not sure what you mean by project manager, but right now, I see no reason why it shouldn't be possible to keep the package/build description very compact. If something gets complex anyway, maybe it should be broken up into multiple packages (e.g. one with the C/C++ stuff + bindings and one using the C++ stuff). > > With a syntax as I suggested or something similar everything is mapped > direct onto an AA and is easily scanned by the build system or other > tools. > > Regarding json: It is designed for data exchange between different > sources, not to be edited by people. It is too annoying and error- > prone to wrap each string into quotes. And people have to edit the > configuration file. Better to start in a well suited format. This is just wrong. JSON is just JavaScript, which is meant for human editing just as D or a custom DSL is. There definitely are nicer syntaxes, but this is putting it out of proportion, IMO. I'm surely not against using a different format, but all arguments must be weighted against each other here.
