Hey Tom,
I'm commenting out of order here, but hopefully it makes sense this
way :)
>
> The other issue that I've mentioned before is that of producing x64 and
> Win32 builds from one source tree/SDK. It seems to me that the hugin
> CMake stuff will differentiate between debug and release libs (at least
> for some 3rd party dependencies), but not for 32 vs 64 bit - it
> generally seems to look for and generate link info for "somelib.lib"
> and
> "somelibd.lib", but not "somelib32.lib", "somelib32d.lib",
> "somelib64.lib" and "somelib64d.lib". Ideally, I'd like to be able to
> freely choose between any combo of x64/Win32 and Debug/Release within
> Visual Studio, and have the build process work. Is there a CMake master
> in the project who might be able to comment on this?
As far as I know, I was the first to really pursue the x64 builds.
What you're describing re: CMake is arguably a limitation both of CMake
itself (and more aptly, it's Visual Studio project generation ability) and a
limitation of the CMake recipes (for lack of a better word). The distinction
between Debug and Release is something that CMake (tool) itself supports via
a language-specific + compiler-specific extension that allows creators of
CMake files (FindGLUT, for example) to specify what the filenames will be.
No such directives exist for platform-specific definitions (that would allow
one to create a .sln that supports Win32 and x64 development). So, at a
minimum, we're talking two .sln files (or nmake, if you prefer) generated
from a single CMake, with a generic variable tracking target platform (which
CMake already sets for you, mind you).
However, once there, it becomes a bit tricker. This is because some
of the (third-party) libraries use MSVC extensions (namely, #pragma
comment(lib, "libname")) to specify what the library name will be, which is
based on arguments you pass to their (non-CMake) build scripts. I recall it
being Boost and STLplus that did this, but it may be more. So you'll still
need to be specifying separate build arguments to these tools, and hoping
to get them to dump their compiled output into separate directories with a
sane naming scheme, which ends up with multiple copies of the include files
as well (since they "deploy" the library once compiled).
At one point, right before enblend-enfuse-4.0 was released, I did
have a system and a set of batch and CMake files that could compile the
entire set of libraries through, but unfortunately I lost those with a drive
crash. It involved touching every Find*.cmake and changing the
paths/libnames it would check based on whether the target platform was Win32
or x64 - which further involved copying/modifying some of the .cmake files
that come with the standard CMake distribution, and copying them into the
local repository so they'd be picked up first. I say that to clarify that
it's definitely do-able, it just requires a lot of CMake hacking, and even
what I had, was so messy that I didn't feel confident committing upstream.
I haven't followed up with CMake development, but they may now
support multi-platform targeting within a single solution, they just didn't
when I last worked on it. Hope that helps.
> I was interested to read that the idea worked on in the past for the
> Win
> SDK is based around a script that downloads 3rd party source/binaries
> as
> needed. I'll see what I can find in the Wiki, but notably I'd be
> interested to know which scripting system was being suggested - perhaps
> NSIS is a good choice?
NSIS is more of an installer system than a build system. The build
system needs to be scriptable, capable of applying patches, and executing
the various custom build scripts (bjam, for example, for Boost compilation).
I've got a lot of experience with NSIS, and feel confident saying "This is
not the tool you're looking for". My original solution was simply a batch
script, but depending on what the lowest common denominator is, you may feel
more comfortable with either a Windows Script Host script (VBScript,
JScript), a PowerShell script, or even a third-party language like
Perl/Python via ActivePerl/ActivePython (though introducing that dependency
just for a build-helper script seems overkill)
Just let me know if you have any further questions and I'll do what
I can to help.
--
You received this message because you are subscribed to the Google Groups
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
