[QBS] Depends and cpp.includePaths

[Ruslan Nigmatullin]

27.02.2012, 16:42, "Joerg Bornemann" <joerg.bornemann at nokia.com>:
> On 24/02/2012 20:51, ext Ruslan Nigmatullin wrote:
>
>>  Modules and Products have different behaviour in context of Depends, i.e Module sets all needed variables like cpp.includePath automatically, but Product doesn't. Should user worry if he uses currently external library or built-in one? Is there any possibility to explicitly set for every dependant Product all needed variables?
>
> The reason is that the properties you set in a Product are for
> _building_ the product. If you want to _use_ the product, you must
> specify a ProductModule and set the properties you need.
>
>>  For example there are lots of cpp.includePaths in every QtCreator's plugin with hard-coded relative path to core libraries, so it's quietly impossible to build them as standalone package. Also all this qbs files have to be fixed in case of moving plugins' directory somewhere to other place.
>
> This should be moved to the ProductModule in src/plugins/core.qbs then.
>
>>  May be library products should be available to be implemented in such way:
>>
>>  DynamicLibrary {
>>       name: "mylib"
>>
>>       // Some additional data to be set for dependant products
>>       // Suggest that path to library is already set automatically
>>       ProductModule {
>>           Depends { "name": "cpp" }
>>           cpp.includePath: [ product.path ]
>>       }
>>  }
>
> I actually would like to keep DynamicLibrary free of the cpp module.
> One could have something like
>
> ---CppDynamicLibrary.qbs---
> Product {
>      type: "dynamiclibrary"
>      Depends { name: 'cpp' }
>      ProductModule {
>          Depends { name: 'cpp' }
>          // useful default properties
>      }
> }

My fault, I have missed that ProductModule is already implemented.

> Also, what is product.path? The source dir of the product? That would be
> just ".". Many projects do not put their source files into the same
> directory as the project file is in. So I'm not sure how valuable this
> default actually is.

Yes, I've meant just ".".
I have some more questions connected to this topic, if you are not against for.

Is qbs user have to name directory with sources in the same way and the same structure as it will be installed in /usr/include directory? Or user must have external pregenerated directory with pseudo headers fore each included header for each "possibly-not-system" library in source dir (for example libpng)? Currently qbs doesn't handle dependencies to generated headers at all (so boo.cpp, which includes foo.h, can be processed before foo.h will be generated, which leads to compile error).

The same issue is reproduced if "cpp" file is generated and it contains Q_OBJECT macro (Generated file "boo.cpp" contains directive for including "boo.moc"). Automoc doesn't handle it at all (as file is not created at the moment when check is performing). If tag "moc_cpp" is set manually qbs crashes. If crash is fixed and artifact for moc is created cpp's "obj" parent doesn't depend on it, so "g++" is called before "moc" and it again leads to compile error.

The only way I found is to scan file for dependencies again right after it was generated and reapplying rules for it (that will add "moc_*" tag for generated files with Q_OBJECT macro). Also may be it's needed to check somehow for generatable headers at includes processing state. For example if "generated/foo.h" with fileTag "hpp" is generated by Rule from "foo.txt" and "boo.cpp" contains "#include <generated/foo.h>" the last one should depend on "foo.h".

Doesn't it contradict with qbs ideas and what are better ways for implementing it with current architecture?