mitkFunctionGetLibrarySearchPaths is not aware of extensions
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	floca
	Jun 26 2018, 5:09 PM

Description

Currently the MITK_RUNTIME_PATH variable (that is used to indicate the search paths for shared libraries (on windows only?) is compiled by ignoring extension pathes.

The logic to compile MITK_RUNTIME_PATH is encoded in mitkFunctionGetLibrarySearchPaths.cmake. Here any known EP gets his/her handcrafted treat. EPs from extensions are completly ignored.

Therefore extensions are not able to influence MITK_RUNTIME_PATH. This is e.g. a problem where an EP of an extension is generated externaly and therfore its libs are not in the default ep/libs folder.

Revisions and Commits

rMITK MITK
	Restricted Differential Revision	rMITKb05716c5e6f2 Fixed T24987

Related Objects

Mentioned In: T27033: Clean up stale remote branches

Event Timeline

floca created this task.Jun 26 2018, 5:09 PM

floca added a project: Request for Discussion.Sep 25 2018, 8:48 PM

Discussed it. For now we will implement an simple solution (simelar to the legacy modulconf pattern) to add additional path from the eps cmakeexternals script.

floca claimed this task.Oct 18 2018, 5:10 PM

floca added a revision: Restricted Differential Revision.Oct 18 2018, 5:23 PM

Pushed new branch T24987-mitkFunctionAddLibrarySearchPaths.

floca closed this task as Resolved by committing rMITKb05716c5e6f2: Fixed T24987.Nov 16 2018, 12:37 PM

floca added a commit: rMITKb05716c5e6f2: Fixed T24987.

kislinsk mentioned this in T27033: Clean up stale remote branches.Jan 25 2020, 9:00 PM

mitkFunctionGetLibrarySearchPaths is not aware of extensionsClosed, ResolvedPublicActions

Description

Revisions and Commits

Related Objects

Event Timeline

mitkFunctionGetLibrarySearchPaths is not aware of extensions
Closed, ResolvedPublic
Actions