Fixed building in clean chroot environment in debian. #1

Closed
MicheleC wants to merge 50 commits from fix/building into master
Owner

Updated cdbs, rules and controls. Still no support for ninja-build.

Updated cdbs, rules and controls. Still no support for ninja-build.
MicheleC added 1 commit 3 years ago
af0b287a3e
Fixed building in clean chroot environment in debian.
Collaborator

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.

--   found 'TDE', version 14.1.0
CMake Warning (dev) at src/libtdebluez/CMakeLists.txt:18 (set):
  implicitly converting 'TYPE' to 'STRING' type.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at src/libtdeobex/CMakeLists.txt:18 (set):
  implicitly converting 'TYPE' to 'STRING' type.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring done
-- Generating done
CMake Error:
  Running

   '/usr/bin/ninja' '-C' '/mnt/DEVELOPMENT/TDE/repo-master/tde/2_bullseye/applications/tdebluez/obj-x86_64-linux-gnu' '-t' 'cleandead'

  failed with:

   ninja: error: build.ninja:1477: multiple rules generate src/libtdeobex/interfaces/introspectableInterface.h [-w dupbuild=err]
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. ``` -- found 'TDE', version 14.1.0 CMake Warning (dev) at src/libtdebluez/CMakeLists.txt:18 (set): implicitly converting 'TYPE' to 'STRING' type. This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at src/libtdeobex/CMakeLists.txt:18 (set): implicitly converting 'TYPE' to 'STRING' type. This warning is for project developers. Use -Wno-dev to suppress it. -- Configuring done -- Generating done CMake Error: Running '/usr/bin/ninja' '-C' '/mnt/DEVELOPMENT/TDE/repo-master/tde/2_bullseye/applications/tdebluez/obj-x86_64-linux-gnu' '-t' 'cleandead' failed with: ninja: error: build.ninja:1477: multiple rules generate src/libtdeobex/interfaces/introspectableInterface.h [-w dupbuild=err] ```
Collaborator

confirmed it is realted to ninja

please advise how to proceed

confirmed it is realted to ninja please advise how to proceed
deloptes closed this pull request 3 years ago
MicheleC deleted branch fix/building 3 years ago
Poster
Owner

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.

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

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.

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

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
  1. modify the cmake files such that dbsuxml2qt3 is called with arguments and thus generated only the specified interfaces
  2. modify dbusxml2qt3 to check if interface is already generated and skip overwriting it (not sure if it will work)
  3. modify the cmake file and lie about the interfaces being generate.

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

Comment from Emanoil (not sure why I got this only by email) <hr/> 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 1. modify the cmake files such that dbsuxml2qt3 is called with arguments and thus generated only the specified interfaces 2. modify dbusxml2qt3 to check if interface is already generated and skip overwriting it (not sure if it will work) 3. modify the cmake file and lie about the interfaces being generate. 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
Poster
Owner

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:

  1. generate interfaces in separate folders or

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

In reply to Emanoil comment above. <hr/> 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: 1. generate interfaces in separate folders or 2. 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.
SlavekB added this to the R14.1.0 release milestone 1 year ago
SlavekB removed this from the R14.1.0 release milestone 1 year ago
This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: TDE/tdebluez#1
Loading…
There is no content yet.