Hi, 2013/2/5 Lionel BELLER <[email protected]>
> Yes, I did use CMake to generate the visual studio environment. > I modified the working directory in CMake. > At this moment there is no need to change directories in CMake. The script take care of all. > My apology, I forgot to set the working directory for the debug. > But I have still the error message "Failed to open revision file at: > .cache/bundle1/version0.0/revision.location" > which leads to the VS crash when calling the bundleContext_installBundle > function. > I can't reproduce this... :S. Can you give me a stacktrace of the problem if you get anything during debugging? But to make things easier, I committed some changes today. These changes take care of the VS project user files. But the files I generate are for VS2012, and probably don't work for you. But if you can give me an example of a .vcproj.user file, I can update the script to generate those. VS takes care of migrating to the newer format. With these files it is possible to set a startup project in VS and then debug that project. For Celix the deploy_* projects are relevant. Eg to test the hello world deployment, set deploy_hello_world as startup project and then simply run/debug it. For me this works without having to change anything in the generated VS files. Anyhow, can you retry the entire build with a clean start without changing paths in the CMake files? Disabling subdirectories (like the examples/gtk parts) is no problem. My structure looks like this: - celix (this is trunk checked out, the source directory in the cmake gui) - celix-build (in here all generated files are located, the binary directory in the cmake gui) This makes it easy to delete a build tree without having any files messing up the sources/cmake files etc. > > -----Message d'origine----- > De : Alexander Broekhuis [mailto:[email protected]] > Envoyé : mardi 5 février 2013 12:25 > À : [email protected] > Objet : Re: celix example under windows > > Hi, > > > 2013/2/5 Lionel BELLER <[email protected]> > > > Hi, > > Here is my setup: > > - windows vista > > - VS2005 > > - CMake (2.8.10.2) > > - GCC (3.2.1) > > - GNU Make(3.81) > > - CUnit (2.1.2) > > - Doxygen (1.8.3.1) > > - ZLib (1.2.3) > > - libcurl (7.18) > > - libapr (1.4.6) > > > > GCC and GNU Make aren't needed. You did use the Visual Studio generator in > CMake I assume? > > Did you have a chance to check the working directory etc? I'll try to make > some changes to the CMake files so that the Visual Studio projects have a > proper setup. > > I now have changed the project settings of the "deploy_hello-world" > project. Changed the working directory to ${build-root}\deploy\hello_world > and set the executable to celix.exe. I also set the PATH in the environment > field. > For me I can now run from within VS and debug it. > > Since VS stores these settings in a user file, I should be able to generate > a file with these settings. > > > > > > -----Message d'origine----- > > De : Alexander Broekhuis [mailto:[email protected]] Envoyé : mardi > > 5 février 2013 11:09 À : [email protected] Objet : Re: > > celix example under windows > > > > Hi Lionel, > > > > I tried the current trunk on my windows installation, and it works. > > Shutting down the running framework runs into some problems, but > > starting it is no problem. > > > > Can you give me some more details on your setup? Like windows version, > > versions of the libraries, cmake version etc. Maybe there is some > > difference in there resulting in this behaviour. > > > > 2013/2/4 Lionel BELLER <[email protected]> > > > > > Removing the .cache directory changes nothing. It will be recreated. > > > > > > I think I've found some problems which are at the origin of the bug. > > > In the main of launcher.c, the function properties_get ("autoStart = > > > properties_get(config, "cosgi.auto.start.1");", line 70) does not > > > recover the desired properties. Autostart stays at null. The program > > > crashes then when the program calls the function strtok (l.89). The > > > variable Config is not null, the file "config.properties" is > > > available in the debug folder. So the problem comes from the > > > function properties_get, but I can't step into the function during the > debug. > > > > > > > Strange, I don't have any problems like this at all.. > > > > > > > > > > The "bundles" directory is in the debug directory, so the program > > > should be able to open those files. > > > > > > > > Did you move the bundles folder yourself? Any chance you forgot the > > config.properties file? This file has to be in the running directory. > > I haven't setup debugging properly in my VS, and only run from the CMD > > at this moment. So I don't know what VS uses as running directory. > > > > Seeing some of your problems it looks as if you have a .cache > > directory with entries in the running directory, but not the > > config.properties or even the bundles directory. > > > > Any way, the working directory has to look like this: > > - bundles/{bundles}.zip > > - config.properties > > > > After running the .cache directory is created by the framework, so > > initially is isn't there and it can be removed without a problem. Any > > required libraries should either be on the path or placed in the > > running directory. > > But, as you mentioned, this is already working. > > > > Can you make sure the files are in the correct place? > > > > If this doesn't help, please let me know, I'd like to get this working > > for you (and other windows users..). > > > > -- > > Met vriendelijke groet, > > > > Alexander Broekhuis > > > > > > > -- > Met vriendelijke groet, > > Alexander Broekhuis > > -- Met vriendelijke groet, Alexander Broekhuis
