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
