Checking for the compiler version at packaging time doesn't work. So, do
it earlier and export a variable for it.
Also fix some variable names to make a check work and avoid cmake
failing in strange ways later on.
This allows gcc to pass response files directly to LD, allowing to build
WebKit libraries using them without hitting command-line length limit.
Also REQUIRES binutils at the proper version, as using binutils 2.17 with
gcc4 isn't working (as doesn't understand some directives).
Some of the work was done as part of issue #30
I did a moderate amount of fixing to the recipe but bzr doesn't
behave very well. So leaving it marked as broken.
It has trouble finding our ssl certs directory. Our wget also
had trouble with certs using the original url in that issue. This
can be worked around at runtime by setting command line or config
options.
When doing a test clone of the bzr repo it failed to completely
check out the source with some odd out of memory error. I seem
to recall bzr having this sort of trouble before on Haiku.
* Fix an upstream problem with the time conversion in the native
system notifications
* Kludge the packaging to put *.so symlinks in the runtime path too.
Not particularly happy about it but I'm sick of dealing with this
recipe. This makes qmake/cmake/etc... happy
* Do not rebuild libz and freetype from CD sources, use the system
ones.
* I had to force a dependency on as$secondaryArchSuffix, otherwise
binutils 2.17 is included in the chroot instead of the gcc4 version.
* The policy checker complains that the packages don't depend on
libstdc++.so, but this should be provided by haiku_x86.hpkg ?
* The patch for IUP fails to apply. I guess this is because of line
ending problems as we work from a zipped source archive. Using "git
apply" manually works, however.
* Fix tecmake to set a soname for the libraries
This currenly fails strict-policy checks because the package doesn't
depend on libstdc++.so, but this should be in haiku$secondaryArchSuffix.
I also had to explicitly depend on the proper version of as, otherwise
the one for gcc2 would be picked up. I suspect one of the dependencies
is wrong, but attempts to use haikuporter --why have failed.
* Fix systray support by removing check for
/boot/common/bin/qsystray. Instead we always return true
when determining if Haiku supports a systray since qsystray
is guaranteed to be installed
* qmake will need some fine tuning. When trying to build other
qt based projects it will insert the wrong link flags
(i.e. -L.../lib... instead of -L.../develop/lib...)
* Rebase the work I did against latest IUP release
* Currently fails to build because IUP wants to generate both Lua 5.1
and 5.2 bindings. It seems we can't build_require both packages to build
the bindings ? (require should be ok, as the libs for each version will
go in different packages in the end).
* Also, port some of the fixes to tecmake to the two other tecgraf libs
using it.
* Untested as secondary on gcc2
* Could use some subpackages like _debug/_demos/etc...
(demos and examples are disabled at the moment)
* Might need some fine tuning of install directories but they're
generally ok. This is things like possibly moving qtconfig
into the preferences directory and putting some of the bin
commands that are currently in the _devel package into an apps
dir.
* Several of the libs and some of the data files from the main
package could probably be put in the _devel package.
