Fixed building in clean chroot environment in debian. #1
Closed
MicheleC
wants to merge 50 commits from fix/building
into master
Loading…
Reference in new issue
There is no content yet.
Delete Branch 'fix/building'
Deleting a branch is permanent. It CANNOT be undone. Continue?
Updated cdbs, rules and controls. Still no support for ninja-build.
I get something else which needs more attention. I wonder if this is just ninja specific. In general the error is correct as introspectableInterface.h is generated multiple times and overwrites the old one. But in the case it is just OK, so there is no need to be so strict.
I don't know if we want to be so strict or we can somehow allow overwriting with ninja.
confirmed it is realted to ninja
please advise how to proceed
Hi Emanoil,
sorry I had a very busy week. Will look into ninja build failure and advice. I can confirm the same behavior here.
I had a preliminary look. There are someissued with building libtdeobex when using ninja. Probably you need to adjust some of the cmake stuff since it seems it is generating the same interface more than once.
As a troubleshooting guide, you can start excludnig all the folders except tdebluez-common, then test build and progressively add more folders. I can see libtdeobex being the first folder failing.
Comment from Emanoil (not sure why I got this only by email)
No, the problem is that when you have Introspectable interface in more then one xml in the same folder and run dbusxml2qt3 it will always generate the Introspectable interface, which will overwrite the previously generated one. (I do not think ninja is so smart - it is just looking what we have put in the _SRC and _HDRS variables. and we have put everything that is generated by dbusxml2qt3). It seems this behavior is caught by ninja and it does not want to proceed. What can be done is
The problem with this would be then building the binary object with the Introspectable included. It means in any case remove the Introspectable from _SRCS _HDRS and leave it only in one place, but then add introspectableInterface.cpp to the library rule
It could be that it applies also to others like dbusbaseNode rootNode etc.
I do not like any of this, but it could be the solution until there is code to load the xml and use it on the fly
What do you think?
BR
In reply to Emanoil comment above.
I don't know tdebluez code in detail and you have a much better understanding of what is going here.
Nevertheless I see 'ninja' behavior as being better than 'make'. If we try to generate the same file twice, 'make' was totally ignoring that, while 'ninja' stops and reports something is not correct.
As a solution, we could either:
generate interfaces in separate folders or
we tell dbusxml2qt3 to generate the files only once. Common files will be generated as a new target and the following targets needing those file will have to be dependent on the common target.
IMO, solution 2. is cleaner and will preserve the location of the generated files, while at the same time eliminating file overwriting.