Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] New Build System (-> xPacks/xcdl)

> On 22 Jun 2016, at 17:32, Doug Schaefer <dschaefer@xxxxxxxxxxxxxx> wrote:
> 
> ... take a look at standard builds ... am thinking of making Make Targets first class citizens for that ... take CMake closer to production... a few CDT plug-ins out in the wild and it’s pretty sad users of those plug-ins have to deal wth managed build settings. ... I need to document what I’m doing to make sure people can review and help give me guidance and help along the way. I’ll start doing that in the next few weeks, especially as I make progress with standard build.

supporting standard builds is fine, but does this mean the focus will shift away from managed builds?

I am also planning to experiment with another CDT build plug-in, for my xPacks/xcdl, but I'd like to think that my builds will be managed builds driven by various json files existing in the packages; manually maintaining cmake files is an absolute no go for my packages.

my managed build system is based on some simple requirements

- the json files should be considered as a kind of metadata that accompany the source files; for example if a folder contains source files, and should be added to the list of configuration source folders, it'll include a small json file that will state this; similarly for include folders; these json files are stored in the same repositories as the source files, and accompany them everywhere. in this way when you compose a project from multiple packages you already have the list of source and include folders available, you no longer have to configure them in the project configuration, as with the current CDT MBS

- the way the content of the json files is designed should reflect an internal status associated with the various objects involved in the build, in other words the json files should be output files of a project manager tool, and not input configuration files, manually created and maintained.

- similarly to cmake, the xcdl build system will not run the build itself, but will generate make files (possibly ninja files) and perform the build as standard as possible.

- it should be possible to perform all operations from a command line



to be noted that the second requirement is a very powerful one, and is my major source of discomfort with cmake: partly due to the syntax, but mainly due to the semantics designed into them, the cmake input files are intended to be created and maintained by humans, and it is extremely difficult (for not saying practically impossible) to have them maintained by an automated tool.


the first component of this build system will be a command line utility called xcdl, probably written in go, somehow similar to the mbed yotta utility. once functional, a set of Eclipse plug-ins will be added, that will either call the xcdl command line utility or perform some of the task natively in java. the main purpose of the plug-ins will be to provide a nice gui to create/edit the xcdl metadata associated with the xPacks packages.


if there is anyone interested in this approach, we can obviously discuss the CDT related issues here, but for the generic issues I suggest to use the "xPacks/XCDL" category of the "GNU ARM Eclipse" forum (http://gnuarmeclipse.github.io/support/forum/).

any feedback will be highly appreciated.


regards,

Liviu



Back to the top