Re: [Qbs] dependency tracking

2020-09-16 Thread Richard Weickelt
>> "testinput.h" file contains "#include "a.h" directive. Changing 
>> testinput.h results in a generator run followed by a C++ compiler run. 
>> Changing a.h results in no action, although in this case the generator 
>> is intended to reprocess its input.
> 
> It's expected that the generator won't re-run, because the dependency
> parsing happens when building a cpp file, i.e. all the headers are
> dependencies of the object file, and the header files themselves are only
> "passed through" by the scanning process. Though you might be able to
> cheat by setting up a dummy cpp file that includes the top-level header
> and making that an input to the generator rule.

As Christian said: The problem is that the cpp scanner is triggered by the
generated cpp file, but there is no connection to the testinput.h because
your cpp files is not including it.

If you could add the following lines to your generated cpp file:

#ifdef IGNORED
#include "testinput.h"
#endif

then this should be enough to make the cpp scanner think that you are
actually including testinput.h and hence, it will see and track a.h as well.

Richard
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


Re: [Qbs] dependency tracking

2020-09-16 Thread Christian Kandeler
On Tue, 15 Sep 2020 22:10:13 +0500
Dan Pat  wrote:

> "testinput.h" file contains "#include "a.h" directive. Changing
> testinput.h results in a generator run followed by a C++ compiler run.
> Changing a.h results in no action, although in this case the generator
> is intended to reprocess its input.

It's expected that the generator won't re-run, because the dependency parsing 
happens when building a cpp file, i.e. all the headers are dependencies of the 
object file, and the header files themselves are only "passed through" by the 
scanning process. Though you might be able to cheat by setting up a dummy cpp 
file that includes the top-level header and making that an input to the 
generator rule.


Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


Re: [Qbs] dependency tracking

2020-09-15 Thread Dan Pat
 Probably, I haven't made myself clear enough. Here's an example setup.
This is a dummy generator's module definition:

import qbs

import qbs.FileInfo

import qbs.TextFile


Module {

id: testgen


Rule {

inputs: ["genxx"]

Artifact {

id: artifact

filePath: FileInfo.path(input.filePath)  + "/" +
FileInfo.baseName(input.filePath) + "-gen.cpp"

fileTags: ["cpp"]

}

prepare: {


var cmd = new JavaScriptCommand();

cmd.description =  'Running test generator';

cmd.sourceCode = function(){

var file = new TextFile(output.filePath, TextFile.WriteOnly);

file.write("const int c = 5;");

file.close();


}


return cmd;


}

}

}

This is a dependent product's description:

import qbs
DynamicLibrary
{Group {name: "generatorInput"files: [
"testinput.h"]fileTags: ['hpp', "genxx"]}
Group {files:["a.h"]}
Depends {name: "cpp" }Depends {name: "testgen" }
}

"testinput.h" file contains "#include "a.h" directive. Changing
testinput.h results in a generator run followed by a C++ compiler run.
Changing a.h results in no action, although in this case the generator
is intended to reprocess its input.


вт, 15 сент. 2020 г. в 17:47, Dan Pat :

> Yes, the product does depend on the 'cpp' module. The include paths are
> fine, since the same header files are later used by the compiler. A little
> more detail: I use the Group language item to tag such headers
> appropriately.
> Assuming that the generator inputs tag is "genxx", the fileTags of the
> Group is  fileTags: ['hpp', 'genxx'].
>
> пн, 14 сент. 2020 г. в 20:52, Jochen Ulrich :
>
>> But it will only scan for dependent header files if the product using the
>> code generator depends on the `cpp` module and if the `cpp.includePaths`
>> are set up correctly, right?
>> Is this the case?
>>
>> Best
>> Jochen
>>
>>
>>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


Re: [Qbs] dependency tracking

2020-09-15 Thread Dan Pat
Yes, the product does depend on the 'cpp' module. The include paths are
fine, since the same header files are later used by the compiler. A little
more detail: I use the Group language item to tag such headers
appropriately.
Assuming that the generator inputs tag is "genxx", the fileTags of the
Group is  fileTags: ['hpp', 'genxx'].

пн, 14 сент. 2020 г. в 20:52, Jochen Ulrich :

> But it will only scan for dependent header files if the product using the
> code generator depends on the `cpp` module and if the `cpp.includePaths`
> are set up correctly, right?
> Is this the case?
>
> Best
> Jochen
>
>
>
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


Re: [Qbs] dependency tracking

2020-09-14 Thread Jochen Ulrich
But it will only scan for dependent header files if the product using the code 
generator depends on the `cpp` module and if the `cpp.includePaths` are set up 
correctly, right?
Is this the case?

Best
Jochen


___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


Re: [Qbs] dependency tracking

2020-09-14 Thread Christian Kandeler
On Mon, 14 Sep 2020 19:11:41 +0500
Dan Pat  wrote:

> Hi, I have a code generator using C++ *.h headers as its input. Everything
> works fine for me except for dependency tracking. Since inputs are ordinary
> include files they often include other include files which include other
> include files etc. The problem is that when an include file included by the
> input file changes the generator is not rerun, because, I guess,  it knows
> nothing about it. 

It should, as the scanning is recursive. If you can provide an example project, 
you could file a bug report.


Christian
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


[Qbs] dependency tracking

2020-09-14 Thread Dan Pat
Hi, I have a code generator using C++ *.h headers as its input. Everything
works fine for me except for dependency tracking. Since inputs are ordinary
include files they often include other include files which include other
include files etc. The problem is that when an include file included by the
input file changes the generator is not rerun, because, I guess,  it knows
nothing about it. The dependency extraction logic should be pretty much the
same as the one used by the built-in cpp scanner. Do I need to write my own
Scanner to do the job, or is there a way to somehow reuse the functionality
already implemented in the cpp module?
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs