bug/3135/build-issues #89
Merged
SlavekB
merged 2 commits from bug/3135/build-issues into master 4 years ago
No reviewers
No Label
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Depends on
Reference: TDE/tdelibs#89
Loading…
Reference in new issue
There is no content yet.
Delete Branch 'bug/3135/build-issues'
Deleting a branch is permanent. It CANNOT be undone. Continue?
Changes to:
dnssd/CMakeLists.txt to include include/link directories for avahi-tqt
kdoctools/CMakeLists.txt and kdoctools/ConfigureChecks.cmake to build and install customization/entities/general.entities using the binary directory
kglib/CMakeLists.txt to add missing glib link directories
tdecore/CMakeLists.txt to add dependency for dcopidl2cpp to ensure it is built before it is used
Here are some comments we should address.
LINK tdecore-shared ${AVAHI_TQT_LIBRARIES} ${AVAHI_CLIENT_LIBRARIES}DEPENDENCIES tdeconfig_compilerLINK tdecore-sharedLINK_PRIVATE ${AVAHI_TQT_LIBRARIES} ${AVAHI_CLIENT_LIBRARIES}Ok, this seems to be safe – I did a test of building tdegames where tdednssd-shared is used and it builds without problems.
DEPENDENCIES tdeconfig_compilerLINK tdecore-sharedLINK_PRIVATE ${AVAHI_TQT_LIBRARIES} ${AVAHI_CLIENT_LIBRARIES}DEPENDENCIES tdeconfig_compiler DCOP-sharedtdednssd-shared depends on tdecore-shared, where tdecore-shared already depends on DCOP-shared – see tdecore/CMakeLists.txt.
Why do you see a reason to add dependency for DCOP-shared here again?
I was running cmake multi-process and getting problems one of which was attempts to link libDCOP before it was ready. I thought I'd removed it when I went back to single process. Given that I've got multiple commits, how do I get rid of it?
It will now be possible to remove not only the DCOP-shared dependency, but also tdeconfig_compiler dependency! See #90.
To do change in a specific commit you can use:
git rebase -i masterpicktoedit.git commitwith the--amendargument to modify the existing commit.git rebase --continueto rebase other commits.git push origin HEAD -fto force a push to the new branch state.# done ;\# done )install( DIRECTORY customization docbook DESTINATION ${DATA_INSTALL_DIR}/ksgmltools2 PATTERN ".svn" EXCLUDE )install( FILES ${CMAKE_CURRENT_BINARY_DIR}/customization/entities/general.entities DESTINATION ${DATA_INSTALL_DIR}/ksgmltools2/customization/entities )If the
general.entitiesfile is to be installed from a binary folder, it should be excluded from installing other files from the source folder.I suppose there's no guarantee as to the order the commands are run in. I'm thinking adding
REGEX "/entities/general.entities$" EXCLUDE
after the existing "EXCLUDE" would do the job. There's an "obsolete/general.entities" that still needs to be copied, so the above would not exclude it. Would that be OK?
Yes, that sounds like a good solution.
# update entitiesmessage( STATUS "Updating ${ENTITIES_FILE}message( STATUS "Updating ${ENTITIES_FILE_SRC}It seems that updating the data to the binary will only work because the
TDE_VERSION_STRING,TDE_RELEASE_DATE, andTDE_RELEASE_COPYRIGHTentities are not currently used in the manuals generated within tdelibs. Here's the question of whether to rely on it?You can see that generating the tdespell manual uses docbook files from the source folder – because of that it gets
general.entititieswith no items added during build.We can either leave it unchanged with the risk that future documentation could fail due to this, or we would have to copy the entire contents of the docbook directory to a binary folder.
VERSION 0.0.0LINK ${TQT_LIBRARIES} ${GLIB2_LIBRARIES} ${GOBJECT2_LIBRARIES}LINK ${TQT_LIBRARIES}LINK_PRIVATE ${GLIB2_LIBRARIES} ${GOBJECT2_LIBRARIES}Ok, this seems to be safe, because kglibs-shared is not currently used anywhere.
LINK_PRIVATE ltdlc-static ${KDESVGICONS} ${XCOMPOSITE_LIBRARIES}${LIBIDN_LIBRARIES} ${LIBBFD_LIBRARIES} ${LIB_UTIL} ${GAMIN_LIBRARIES}DESTINATION ${LIB_INSTALL_DIR}DEPENDENCIES dcopidl2cppOk, it seems that the idea of setting the dependence on the level of the common cmake module does not work as intended. I'm trying to find a solution at the level of a common cmake module that could work as intended – so that there is no need for an explicit dependency specification.
I will try to solve the same one also for the dependency on
tdeconfig_compiler.I have come across problems building tdelibs multi-process, but this one cropped up running single-process.
Yes, I did a single-process build test and I got the same problem. Thanks to change #90 there is no need to add an explicit dependency here, as well as dependencies that were used in the common TDE CMake module can be removed! That's a better solution than I hoped.
You can rebase your PR to the current master:
Because the changes between the master and your branch are consistent, there should be an automatic merge without having to manually resolve conflicts. Then you can push using force.
OK, done that.
Now I noticed – in the original design, for tdednssd-shared you suggested moving
{AVAHI_TQT_LIBRARIES} and{AVAHI_CLIENT_LIBRARIES} to LINK_PRIVATE. Now it's gone. Was it discarded on purpose?I moved them to LINK_PRIVATE more as a precaution, but I think the only other one that has a problem with not finding it is tdebase. I was having some problems trying to get things to refresh properly and I think I managed to lose that particular alteration along the way. I can put it back if you think it's a good idea.
Moving libraries to LINK_PRIVATE for tdednssd-shared seemed like a good idea. So yes, you can put it there.
Great, it looks good.
2c6417b8d6.