Hi Ingmar,
On 02/18/2015 05:02 PM, Ingmar Wegner wrote:
Hi Sascha,
I have covered everything in [1] and [2].
I set up my module to contain usFunctionGenerateModuleInit call as
mentioned in [1] and configured cmake to place the dlls inside a
subfolder /mesh/debug underneath the bin folder.
I have double checked that everything defined in cmake also has an
impact so in my modules visual studio subproject there is a
preprocessor definition US_MODULE_NAME=mesh and the us_init.cpp file
gets generated and added to the solution.
Sounds good so far.
But the load mechanism doesn't search for the directory.
I would desperately need a description of how the US_MODULE_NAMEs or
so get into the list of loaded directories.
Sorry for being so pushy... and hope to also help others when merging
to MicroServices.
No problem. I guess this tells me that [2] isn't written very well...
There is only one list which contains "auto-load paths" for looking up
the shared libraries which should be auto-loaded. These entries are not
related to any US_MODULE_NAME definition at all.
The last bullet point in [2] tries to explain this:
"For each auto-load path, all modules in that path with the currently
loaded module's auto-load directory appended are explicitly loaded."
So take the MitkCore library. Its auto-load directory defaults to its
module-name, so it is "MitkCore". Assume the list of auto-load paths
contains only the entry "/my/bin". When the MitkCore library is loaded
(usually due to a linker dependency), the CppMicroServices code looks
into the directory (plus some heuristics for debug/release directories)
/my/bin/MitkCore
and if it exists, loads all shared libraries from that directory. Thats
it. The loaded libraries could be anything. If there are more auto-load
path entries, this process is repeated for every entry with the
"MitkCore" string appended. This happends for every module which has a
non-empty auto-load directory.
Does this help?
- Sascha
Ingmar
*Gesendet:* Mittwoch, 18. Februar 2015 um 14:36 Uhr
*Von:* "Sascha Zelzer" <[email protected]>
*An:* "Ingmar Wegner" <[email protected]>
*Cc:* mitk-users <[email protected]>
*Betreff:* Re: Aw: Re: [mitk-users] Migration to MicroService based IO
Hi,
quick answer:
Please read [1] for the module name stuff.
The auto-load directory settings (search paths and module directory)
is explained in [2].
I might be able to look into it in more detail later.
Best,
Sascha
[1] http://docs.mitk.org/2014.10/MicroServices_TheModuleContext.html
[2] http://docs.mitk.org/2014.10/MicroServices_AutoLoading.html
On 02/18/2015 02:29 PM, Ingmar Wegner wrote:
Hi Sascha,
once more thank you for your patience.
I invested some time in getting the other io modules to also be
loaded from their /<modulename>/<build_type> directory and didn't
get it to work. I started with a new target directory to prevent
the build system to load variables that might have been definded
during my tests.
Turned out, that my current approach was noch working. The
MicroService auto load section doesn't scan for my "mesh" dir any
longer.
So I asume, that something got set up while I was trying to get it
working. As I also tested with cmake calls I compared the working
target dir with the new one.
But the problem is that the working one contains as well
definitions from an older mitk version, (2014.10.0) where the new
directory structure was not in place.
I searched for a list that contains all auto load modules and
found the modulesConf.cmake files, that are no longer in the new
structure, right?
I also tried to debug up where the module strings (info) comes
from but got lost in the US_GLOBAL_STATIC_WITH_ARGS method in
usStaticInit_p.h. That sounds like a possible source though.
I asume, that if I would use the CreateModule macro everything
would work.
*As we are using our own cmake structure could you possibly
explain how the module name gets into the list of scaned directories?*
Best Regards,
Ingmar
*Gesendet:* Mittwoch, 18. Februar 2015 um 09:21 Uhr
*Von:* "Ingmar Wegner" <[email protected]>
*An:* "Sascha Zelzer" <[email protected]>
*Cc:* mitk-users <[email protected]>
*Betreff:* Re: [mitk-users] Migration to MicroService based IO
Hi Sascha,
thank's alot for the advice.
I got it to work for the one module. Below is a log of my setup.
In CMakeLists.txt of my module I am calling
...
set(module_name ${PROJECT_NAME})
set(US_MODULE_INIT_TEMPLATE
${MITK_SOURCE_DIR}/Modules/CppMicroServices/CMake/usModuleInit.cpp)
# a us_init.cpp file will be generated and has to be added to sources
list (APPEND _SRC_FILES "${CMAKE_CURRENT_BINARY_DIR}/us_init.cpp")
usFunctionGenerateModuleInit(_SRC_FILES)
add_library(
...(continued in my original/first post of this thread)
When I additionally call US_INITIALIZE_MODULE in the module
activator below
US_EXPORT_MODULE_ACTIVATOR(MY_NAMESPACE::MeshActivator) then the
compiler argues: "mesh_activator.obj : error LNK2005:
_us_import_module_initializer_mesh already defined in us_init.obj"
A us_init.cpp is generated in my target/my_module directory, so
that works.
Debugging MITKWorkbench I can see that initializing
CppMicroServices the app looks for
"Z:\build\MITK-build\bin\Debug\CppMicroServices" (which doesn't
exist) then for "Z:\build\MITK-build\bin\CppMicroServices\Debug"
(which doesn't exist either).
Then after no service was found it continues with "MITKCore",
calls MitkCoreActivator::Load(...) and then checks for
""Z:\build\MITK-build\bin\Debug\MitkCore" where it doesn't find a
directory and continues with
"Z:\build\MITK-build\bin\MitkCore\Debug" where it finally finds
the directory. By the way, same is done with search string
"MitkMapperExt" and a lot of other module names but all without
success (path invalid).
So I debugged my application and placed the mesh.dll in
...target_win64-vc12\_runtime\MitkCore\Debug and then the module
was auto-loaded.
Afterwards AutoLoadModulesFromPath(...) looks for "mesh" so I can
also place it into ..target_win64-vc12\_runtime\mesh\Debug and it
will work.
Continuing, it also tries to find all mitk auto load modules in by
apps target directory. Is this worth optimizing towards only
checking the ones that we know they are in the target folder?
Thanks for your great work; we all appreciate the work you all do
on MITK a lot.
Ingmar
*Gesendet:* Dienstag, 17. Februar 2015 um 21:49 Uhr
*Von:* "Sascha Zelzer" <[email protected]>
*An:* "Ingmar Wegner" <[email protected]>
*Cc:* mitk-users <[email protected]>
*Betreff:* Re: Aw: Re: Re: Re: Re: [mitk-users] Migration to
MicroService based IO
Hi,
does your executable contain "module initialization code" as
mentioned?
Did you try the "MitkCore" sub-directory?
In your MITK (not superbuild) CMake cache, you can set the
US_ENABLE_DEBUG_OUTPUT variable to ON (needs to be manually added
in the CMake GUI or on the command line). After recompiling MITK,
this will give you debug messages including auto-load stuff.
The relevant code is here:
https://github.com/MITK/MITK/blob/master/Modules/CppMicroServices/core/src/util/usUtils.cpp#L109
Thanks,
Sascha
On 02/17/2015 09:34 PM, Ingmar Wegner wrote:
Hi Sascha,
I tried the following situation, but nothing worked out.
The application is in:
target_win64-vc12\_runtime\debug\my_application.exe
I tried
target_win64-vc12\_runtime\debug\main\my_module.dll
target_win64-vc12\_runtime\debug\main\debug\my_module.dll
target_win64-vc12\_runtime\main\my_module.dll
target_win64-vc12\_runtime\main\debug\my_module.dll
target_win64-vc12\main\my_module.dll
target_win64-vc12\main\debug\my_module.dll
Could you possibly point out where the auto-load plugin code
is situated? Then I can debug it more closely.
Besides, did anyone also experience the warning messages in
the console?
It states 2x4 times at the end of startup:
void __cdecl QWindow::setTransientParent(class QWindow *)
QWidgetWindow(0x61f7fc0, name = "QWidgetClassWindow") must be
a top level window.
This is surely QT5 related.
Have an nice evening,
Ingmar
*Gesendet:* Dienstag, 17. Februar 2015 um 15:49 Uhr
*Von:* "Sascha Zelzer" <[email protected]>
*An:* "Ingmar Wegner" <[email protected]>
*Cc:* mitk-users <[email protected]>
*Betreff:* Re: Aw: Re: Re: Re: [mitk-users] Migration to
MicroService based IO
Hi,
as explained below, the auto-load module must be placed in a
subdirectory name "main" or "MitkCore" which is located at the
same level as your application's executable (not in the same
directory as your executable).
Best,
Sascha
On 02/17/2015 02:47 PM, Ingmar Wegner wrote:
Hi Sascha,
then the library is not loaded and the Load() method of my
module activator is never called.
The module lib is located in the same directory as my
application and my plugins. We don't consider having a
dedicated plugins folder for now.
Best,
Ingmar
*Gesendet:* Dienstag, 17. Februar 2015 um 14:22 Uhr
*Von:* "Sascha Zelzer" <[email protected]>
*An:* "Ingmar Wegner" <[email protected]>
*Cc:* mitk-users <[email protected]>
*Betreff:* Re: Aw: Re: Re: [mitk-users] Migration to
MicroService based IO
Hi Ingmar,
On 02/17/2015 12:09 PM, Ingmar Wegner wrote:
HI Sascha,
with your hint I was able to register the io service.
Still have to set the io lib as pre-load library
parameter though.
What happens if you don't? For auto-load modules, this is
redundant (if the auto-loading works).
Best,
Sascha
But I will continue my work on this once I have
everything compiling and running.
As I recently updated my fork to the mitk master I now
have problems with the new directory structure.
I will write a seperate mail on this.
So thank you for your help,
;) Ingmar
*Gesendet:* Freitag, 13. Februar 2015 um 16:07 Uhr
*Von:* "Sascha Zelzer" <[email protected]>
*An:* "Ingmar Wegner" <[email protected]>, mitk-users
<[email protected]>
*Betreff:* Re: Aw: Re: [mitk-users] Migration to
MicroService based IO
Hi,
we essentially have the same set-up with our internal
code base.
Please read [1] for information about auto-load paths.
The activator of the MitkCore module adds the path
containing the running executable to the list of
auto-load paths, so putting your module's shared
library into <your-exec-path>/main (if your executable
contains CppMicroService initialization code) or
<your-exec-path>/MitkCore should work out of the box.
Best,
Sascha
[1]
http://docs.mitk.org/2014.10/MicroServices_AutoLoading.html
On 02/13/2015 03:51 PM, Ingmar Wegner wrote:
Hi Sascha,
in general I build up linker dependencies to the
modules in my plugins. And before I had an awkward
dependency from the app plugin to the modules that
provide IO functionalites. In my
WorkbenchWindowAdvisor I was registering the
ObjectFactory of each module, so to say.
This time, with the micro service, I hoped to have
a loose way of loading the services during startup
and have them automatically registered to the MITK
IO service in case they are there.
As I have an external project that links aginst
MITK the solution with copying the shared lib into
MITK-build is not possible. How does it work in
the installed case by the way?
Is it possible to add a directory that has to be
parsed for auto-loading?
Thanks for the quick response,
Ingmar
*Gesendet:* Freitag, 13. Februar 2015 um 15:14 Uhr
*Von:* "Sascha Zelzer" <[email protected]>
*An:* "Ingmar Wegner" <[email protected]>, "Mitk
Users" <[email protected]>
*Betreff:* Re: [mitk-users] Migration to
MicroService based IO
Hi Ingmar,
how is your module supposed to be loaded? By a
linker dependency or as a "auto-load" module? In
the latter case you need to make sure that the
shared library is created in the proper
sub-directory (e.g. MITK-build/(bin|lib)/MitkCore)
Best,
Sascha
On 02/12/2015 11:03 AM, Ingmar Wegner wrote:
Hi all,
I am merging our readers and writers to the
new micro service based apporach but am
probably missing something.
I basically stuck to Stefan K. approach for
migrating the simulation module (*Bug 18640*
<http://bugs.mitk.org/show_bug.cgi?id=18640>).
Before I was registering the ObjectFactory in
my WorkbenchWindowAdvisor but now the autoload
feature of my written micro service is
supposed to do that.
Setup:
MSVC 2013 X64 QT 5.4 (!)
MITK checkout from 30 Jan 2015 but might stick
close to the trunk until the next release once
I have it working.
The easiest example of mine is my own vrml
reader and writer.
So for now I implemented an activator and one
vrml_io class that contains Read() and Write().
The Activator::Load() method though is never
called!
(Object factory and serializer are neglected
as long as the module doesn't load.)
I am calling
US_EXPORT_MODULE_ACTIVATOR(MyActivator);
in the body of my activator.
I have to mention that I am manually setting
properties in my cmakelists.txt file as I am
not using the macros provided by mitk.
see following section:
#start CMakeLists.txt
# Registering as mitk module with MicroService
functionality
# set template file
project(mesh)
... # ...including file.cmake
set(module_name ${PROJECT_NAME})
set(US_MODULE_INIT_TEMPLATE
${MITK_SOURCE_DIR}/Core/CppMicroServices/CMake/usModuleInit.cpp)
... # ...calling add_library(...)
#Define US_MODULE_NAME needed for MITK
MicroService
set_property(TARGET ${PROJECT_NAME} APPEND
PROPERTY COMPILE_DEFINITIONS
US_MODULE_NAME=${module_name}) # otherwise it
complains about a not set module name
set_property(TARGET ${PROJECT_NAME} PROPERTY
US_MODULE_NAME ${module_name})
#end CMakeLists.txt
I tried to debug the other working loading
modules but didn't find a difference why my
one shouldn't start.
Do I have to untangle some cmake magic done in
the MITK_CREATE_MODULE macro?
Which example is best for such a job?
The one in modules/core is written to also
contain VTK and ITK IO and doesn't seem to me
as a good example for an external project.
Best Regards,
Ingmar
P.S. Can't wait for the users meeting in April!
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and
Dashboards with Interactivity, Sharing, Native Excel Exports, App
Integration & more Get technology previously reserved for
billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk_______________________________________________
mitk-users mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
