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

[Doug Schaefer <dschaefer@xxxxxxxxxxxxxx>]

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

>
>> On 23 Jun 2016, at 00:00, Doug Schaefer <dschaefer@xxxxxxxxxxxxxx>
>>wrote:
>> 
>> ... Iąm not sure how much time it saved
>> users over simply having a well structured Makefile.
>
>in my case, a project is build from a collection of xPacks with
>dependencies between them. inside each pack there are multiple
>components, which being collections of source files or folders, again
>with multiple dependencies between them and from configuration options.
>
>I'm not sure I understand your approach. how do you expect the user to
>manually maintain "a well structured Makefile" for this?
>
>in my design each xPack contains all details required for the build
>(where are the source folders, where are the include folders, and what
>are the compile options for each folder/file), so automatically
>generating the Makefile is not only possible, but expected.

What you're doing is pretty different than what I was talking about. My
statement is more about Managed Build and why I'm not sure it's the best
approach for a lot of use cases and how we need to support use cases such
as yours better.

>
>> 
>>> and to extract the configuration required by the indexer, please let me
>>> know.
>> 
>> Thereąs been discussion in CDTąs Bugzilla on how to do that. The
>>thinking
>> is that we can get that information out of CMake. That is a major
>> requirement for our CMake support I mentioned in my original post and
>>will
>> be there one way or the other.
>
>since you mentioned you'll be working on the indexer, please be sure that
>in the new design you do your best to match the options used by the
>indexer with those used by the build.

That's the beauty of it, the build system integration tells us what the
options are. It's totally up to that integration/extension to manage that.
As an example, I have very different methods for Qt (running qmake -query)
than for Arduino (using the same model I use to generate the Makefile). I
envision for standard build, or freeform build, to run make in it's dry
run mode initially to give me all the commands it can and then enhance
that with information I get from the build output at build time. Lots of
different ways to do things. You just pick the one that best suites your
build system.

>
>one temptation is to over-simplify things and assume all files are
>compiled with the same options/macros, but this is not the case, the
>indexer should be able to use different configurations for different
>folders/files.

That's the direction we've been heading for a while, where the scanner
info is done per file and the options can be different for every file. In
fact, with my new system, I've eliminated the per project settings
approach all together.

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