Re: [cdt-dev] New Build System (-> xPacks/xcdl)

[Doug Schaefer <dschaefer@xxxxxxxxxxxxxx>]

On 2016-06-22, 12:55 PM, "cdt-dev-bounces@xxxxxxxxxxx on behalf of Liviu
Ionescu" <cdt-dev-bounces@xxxxxxxxxxx on behalf of ilg@xxxxxxxxxx> wrote:

>
>> 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?

For me, yes. Others may keep managed build going, but there really hasn¹t
been a lot of contribution in that area for some time now.

>
>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.

As you mention, this is similar to CMake, and is essentially an external
managed build, which is what CMake and qmake are, then the new build
system would help you integrate this with CDT. The whole philosophy is to
not do build and leave that totally up to the integrator. The main job of
this system is to provide CDT with enough information about the build to
enable the indexer and other key features to work. That should give you
the flexibility you need.

But I need to write this up and explain it better.

Just out of curiosity, if it is similar to CMake, why not just use CMake?
I¹ve been poking around with interest in FreeRTOS support for ESP8266 and
Cortex-M4 platforms and it seems you can use CMake for bare metal with a
few lines in your toolchain file.

>
>
>regards,
>
>Liviu
>
>_______________________________________________
>cdt-dev mailing list
>cdt-dev@xxxxxxxxxxx
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
>https://dev.eclipse.org/mailman/listinfo/cdt-dev