On 1/7/13 4:25 AM, Peter Åstrand wrote:
>> (3) CMakeLists.txt in the FLTK build system needs to be patched as
>> follows:
>> Otherwise, it will try to add -lpng to all of the subsequent function
>> checks, which causes them to fail on some machines (including mine.)
>
> Have you reported this to the FLTK folks? Again, probably makes sense to
> wait with further debugging on this until we have 1.3.2.
No, because it's frankly not my problem, and it would be a lot quicker
for you and Pierre, who have inroads into the FLTK project, to report
it. I am assuming that, if you are interested in making the TigerVNC
build user-friendly, you will want to follow these suggestions. I've
already worked around the issues in my own local build. I submitted
these issues to you both as a favor and so users who inevitably try to
build TigerVNC from trunk and come up with the same issues will be able
to google for them. I build TigerVNC only for reference, so I am not
getting paid to solve any broader issues with that code base or with FLTK.
>> (4) Fluid build fails on Mac using CMake unless CMakeLists.txt in the
>> FLTK build system is patched as follows:
>
> As point 3), I think.
No, because this is a bug introduced by the patches that Cendio made to
FLTK. All I'm suggesting is to extend fltk-1_v6.3.x-keyboard-osx.patch
so that it adds '-framework Carbon' in the CMake build system the same
way it already does in the autotools build system. Don't see why you
have to wait for 1.3.2 for that, since this is not an upstream problem.
It's a problem created by an FLTK patch that was specifically made for
the purposes of TigerVNC.
>> (6) The TigerVNC build will fail unless I patch TigerVNC's
>> CMakeLists.txt as follows:
>>
>> --- CMakeLists.txt (revision 5021)
>> +++ CMakeLists.txt (working copy)
>> @@ -265,6 +265,7 @@
>> if(X11_Xcursor_FOUND)
>> set(FLTK_LIBRARIES ${FLTK_LIBRARIES} ${X11_Xcursor_LIB})
>> endif()
>> + set(FLTK_LIBRARIES ${FLTK_LIBRARIES} png)
>> endif()
>>
>>
>> This goes away when building FLTK with -DOPTION_USE_SYSTEM_LIBPNG=0, but
>> distribution vendors will run into this problem, since they'll probably
>> want to use the system libpng. Since the patch above does no harm when
>> using FLTK's internal PNG library, I would suggest going ahead and
>> applying it to TigerVNC.
>
> Shouldn't this go into vncviewer/CMakeLists.txt instead?
Effectively, it probably doesn't matter either way, since FLTK is only
used when building vncviewer, but since libpng is a dependency
introduced by FLTK, it made sense to me to include it in FLTK_LIBRARIES.
But either way you want.
>> (7) Building FLTK using MinGW is problematic because of the dependency
>> on the libgcc and libstdc++ DLL's. These dependencies are automatically
>
> Yes, this is somewhat problematic, but as you point out, this is really
> a problem with FLTK rather than TigerVNC.
You keep saying that, but I'll say again like I said before-- this is
effectively a regression in the TigerVNC build, because this problem did
not exist in the 1.2 build by virtue of the fact that FLTK was being
built in tree. If a user wants to build a workable Windows version of
TigerVNC from trunk, they currently need to seriously hack the FLTK
build system like I did. But whatever. If you want to throw the most
popular client platform under the bus, then that's your decision to
make. Just understand that, the more frustrating you make TigerVNC, the
more you drive users away, and you should ask yourself where those users
are being driven to and why I have such intimate knowledge of their
frustrations with TigerVNC.
>> (8) You are using ImageMagick to generate tigervnc.png. Of course
>> ImageMagick is not available on Windows, so the Windows build fails. I
>> mean, seriously, check the PNG files into SVN. They're all of, what, 2
>> kilobytes?!
>
> I have no objections to checking in the PNG files, but is this really
> enough? Have you tried running the build with the PNG files already in
> place? My guess is that CMake and the make files will still look for
> "convert" etc and fail if it's not available. We would probably need
> some kind of logic that only looks for "convert" if the PNG files needs
> remake.
The problem is that Windows has a "convert" executable that's part of
the operating system, but of course it is not the right "convert"
executable. On Linux, if ImageMagick is not installed, the build fails
cryptically with "cannot find /usr/bin/convert" or something like that.
Rather than argue, I checked in a patch (5024) that I have verified to
fix the issue and build correctly on all platforms. If you don't like
it, back it out. But if you choose to keep using ImageMagick to
generate the icons, then you need to (a) document that as a build
dependency for Linux/Unix platforms and (b) add logic to
media/CMakeLists.txt to ensure that it doesn't try to build the icons on
Windows.
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Tigervnc-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
