Well, thanks for the help.
But this isn't really what I meant. Again, I can build. In fact, and to
be more precise, I used to do it as you mention with NMake. I changed to
use a msbuild instead of nmake simply because it is faster (msbuild uses
all cores and builds several projects at the same time and whatnot). But
the point is that it doesn't matter if one builds from the command line
or generates the solution, opens visual studio, sets the configuration
to debug, then builds and then install. The install project will fail
within visual studio just as it does when doing it from the command line
as I describe (I tested it). It is true that one can ignore it (also
giving up stepping in the applications) when doing all these steps by
hand. But in automated builds, this breaks the build process. That is
why I thought it would be interesting to report it to the list. Though,
well, maybe is not that important. :-)
Regards.
On 25/09/2017 16:33, Julien Valentin wrote:
Oups sorry mea culpa
I didn't know you could build through cmake
It s been a while since i didn't do that but if the point is to build under
windows via command line, i remember have done something like this:
Code:
%MSVCPATH%/vcvarsall.bat
cmake -g "NMake Makefiles" .
nmake
Hope it helps
SMesserschmidt wrote:
Hi,
wow
It seams you're clearly overthinking required command line arguments..
try using
Code:
cmake-gui %OSG_ROOT%
instead
..and don't forget to delete CMakeCache.txt..
No, he's building it. Not configuring the project. The syntax is correct.
Cheers
Rollastre Prostrit wrote:
Hi list.
I am not such an expert in CMake to say it for sure. In fact, I basically only know how
to use it. Never did a sophisticated script myself. But it looks to me that some
CMakeLists.txt in OSG v3.4.1 has a problem when building for MSVC in debug (and in my
particular case in 64 bit but I think this is not relevant). In short, it
"fails" when installing with this command
cmake --build . --target install --config Debug -- /p:Platform=x64 /m:8
And the problem is that the installation script looks for pdb files of OSG
applications (e.g. osgviewerd.exe and whatnot) which are not created. This
happens after all the usable files have been installed. So one could disregard
this error value returned. After all, what it is partially installed seems to
be usable. But if you are building OSG in an automated fashion this flags the
build as failed and it stops all the build system.
However if the solution files are generated with the
-DBUILD_OSG_APPLICATIONS=no parameter, the build and installation works
smoothly (though of course you won't have the applications built but maybe that
is ok for some).
So, the solution here seems to be that either the .pdb files are created for
the applications too, or the install target for the applications doesn't try to
install them. What happens now (in my machines at least) is exactly the
opposite. Applications don't generate the .pdb files and the install script is
trying to install them.
As I said before, I am not that cmake-skilled to spot where the problem is
within all the scripts and provide a solution. But it would be nice if someone
could.
Thanks.
------------------
Post generated by Mail2Forum
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=72059#72059
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
------------------
Post generated by Mail2Forum
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=72066#72066
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
