1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
Here is the current (2013-12-06) epa_build ToDo list.
* Add a build configuration for Qt4_lite. As far as I can tell
(despite all the excitement over the years concerning the
CMake-based build system for KDE) the build system for Qt4 is an
autotools-based one, see
<http://www.linuxfromscratch.org/blfs/view/svn/x/qt4.html>. Note
the prerequisities mentioned on that blfs page are Linux
prerequisites. So I attempted to find out more about Windows
platform requirements by running the configure script from
MinGW/MSYS/Wine with the --help option. That bombed out (saying
something about the platform not being ready) so I tried specifying
the platform before asking for help using these configure options:
-platform win32-g++ --help. That worked, and showed, for example,
all the X11 options had disappeared. I determined that platform
string following the directions in
<http://stackoverflow.com/questions/5211188/what-are-the-different-platforms-for-qts-configure>)
which said to use the same name as one of the subdirectories in the
mkspecs subdirectory of the top-level of the Qt source tarball.
From that method, another alternative platform string was
win32-g++-4.6, and looking at that subdirectory in more detail, it
obviously is an (extremely minor) update to win32-g++ so from now on
I intend to use the later platform string, i.e., -platform
win32-g++-4.6 because my MinGW version is 4.7.2 and not something
earlier than 4.6.
My guess is the Windows version of Qt4 is essentially a standalone
version with no outside dependencies. In contrast from the BLFS
remarks, the Linux version has lots of dependencies, and if you
follow those up you would have to create and test epa_build
configurations for many additional software packages including some
difficult-to-get-right security packages such as openssl and the
security certificates. So the strategy I intend to use is specify
no dependencies for Qt4 (which will mean the Linux epa_build of Qt4
will depend on some pre-existing system libraries which is OK, and
it should likely not be an issue for the Windows epa_build of Qt4 if
that is truly standalone). Furthermore, I will attempt to make the
Qt4 build as quick and "lite" as possible by dropping as much as
possible from the configuration that does not interfere with PLplot
use, and for components that are used by PLplot such as jpeg, use
the in-house Qt4 version of that library rather than the system
library (which again reduces or avoids dependencies for the Windows
case).
Later on, of course, if somebody was interested they could configure
a more complete and powerful form of epa_build configuration of Qt4
that was suitable, for example, to support even an epa_build
configuration for KDE. But for now I am going to concentrate on
Qt4_lite.
* Test whether the current build_plplot_lite works for the current
wine (1.6-rc4) that I have built. This has worked in the past
so I expect only minor issues to show up for this case.
* Attempt to add a Tcl8.6 and friends buildtools for the Wine case.
If this works, then try build_plplot_lite on Wine again. Our normal
Tcl test targets such as test_pltcl_standard_examples and
test_tclsh_standard_examples, should work, and there is also a good
chance that test_c_ntk will work also since -dev ntk only depends on
Tk and not X. Of course, our other Tk test targets (test_c_tk,
test_plserver_standard_examples, test_wish_standard_examples,
test_plserver_runAllDemos, and test_wish_runAllDemos) will not work
on this platform because all the PLplot Tk functionality exercised
by those tests ultimately depends on -dev xwin and X.
* Update to the latest Wine and verify that build_plplot_lite continues
to work in that case.
* libcurl build configuration following the specific libcurl
information (and all its dependencies) in Linux from Scratch
<http://www.linuxfromscratch.org/blfs/view/svn/basicnet/curl.html>.
A build configuration success with libcurl would free epa_build
users of the need to rely on binary versions of CMake which is a
worthwhile goal although an extremely low priority compared to Qt4_lite
since ABI incompatibility is not an issue with binary
downloads of CMake (since that is just an application) while they
are an issue with binary downloads of the Qt4 set of libraries.
In fact, I may never bother to configure libcurl since it has a lot
of dependencies and some of those (like openssl and security certificates)
seem difficult to get right.
|
