Hi Ryan,
Thanks for all that info - I'll digest it and do some research. One
comment re NSIS - I certainly wasn't thinking of using it for building,
but more in response to Yuv's note about downloading dependent
source/binary packages. Windows doesn't come with wget as standard, and
I'm not clued-up on some of the more enterprise-oriented scripting stuff
that later versions of Windows support, so I was thinking that NSIS
would be a useful tool for managing these downloads and for generally
bootstrapping the installation (but not the build) of the SDK without
requiring the user to download and install several utilities by hand in
advance.
Another note: As it stands, there are a few patches required to 3rd
party libs that go beyond .sln file mods, and actually touch source
code. From what various people have said, and the convention in use for
the do-it-yourself SDK, I understand that the desired option is to
download the unmodified source code of a specific version from a given
library's main repository, then apply hugin-specific patches if needed.
Is there general agreement with this (or at least lack of disagreement)?
Tom
On 16/05/2010 11:19 PM, Ryan Sleevi wrote:
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
