Thanks Przemek.
I'll look into this header package problem tomorrow.
One thing that would help a lot here, is to have a
separate include dir inside the Harbour source tree,
which is empty in the repository, and where these
headers could be spilled from the 3rd party header
zip file.
Such a folder could be /include/3rdparty/ or
/include/usr/
Then, all make our systems could be extended to look
for headers in that folder too.
Otherwise, we'd need to end up spilling lots of foreign
header files into /include/, which is not very good,
maybe even a show stopper, or I need to rethink the
way BC/VC non-GNU makes files are looking for the
headers to be compatible with this new method (currently
these are getting the root path of the package, and
each contrib will "know" where to look for headers
inside that package root dir)
I'm not sure I was clear :-/
Brgds,
Viktor
On 2008.02.09., at 13:53, Przemyslaw Czerpak wrote:
On Fri, 08 Feb 2008, Szakáts Viktor wrote:
[...]
With all due respect if someone creating an official
binary release is not able to do this, we may have some
other problems too.
Viktor, the most important is that it will be necessary to make
some modifications before compilation. I intentionally always
tried to reduce them to avoid problems and typos during manual
updating.
I do not expect that packager will have any deep knowledge
about OS or programming. I only want to ask him to run one
of the build script and send us the results. It will greatly
reduce differences between binary builds of the same release
we had in the past. I also think that it will be good to add
sth like make_tgz.sh for Windows users who do not use *nix
like shell for BCC, MSVC, POCC binaries. We also still do not
have make_os2.cmd which is necessary for OS2 users - now they
are using make_gnu.cmd from older Harbour versions or from
xHarbour.
As an alternate solution we might as well distribute
all those headers as a separate download, so that all
headers can be copied to one dir, or to each contrib
dir, and do the build as usual. This way it's not in
the SVN, but still easy to access for everyone with
just one easy extra step (to be done once) to extract
to /include/.
I can even prepare such a file.
What do you think about it?
It will help and maybe it's quite good final solution though
it will not resolve the problem of RPMs for cross builds when
user do not have write access to cross compiler environment.
But I do not understand why it's important to make the packagers'
life harder during RC tests. We already spend more time discussing
it then it's worth. Anyhow I'll update spec files and add optional
support for zlib so if someone will want create Harbour RPMs native
or for cross build (Win32 and WinCE) with ZLIB support then it will
be necessary to use --with zlib switch. Of course after adding the
header files to one of include paths. At least it will reduce the
problem.
I can understand your POV and I'd definitely miss your
contributions. I also plan to move away, especially since
I still have no direct business interest in contributing
to Harbour, but other things are constantly growing on me.
Maybe making a few clients switch to the Win32 version of
my app could change that.
Each of us has own life which is the most important of us.
I will also miss your contributions.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
