Hi Przemek,
Any more pointers (like build std/err log)? I can't
see any trends in this list, which could help trace
these back to any recent modifications.
libhbmisc.a is the simplest lib without any Makefile
tricks, so I wonder how could it fail like this.
The modifications in contrib make files completely broke
RPM creation process and now it has to be changed. I'll
try to look at it and maybe I'll be able to fix it.
Anyhow some of recent modifications will make this process
harder. Please note that moving build conditions into
separate Makefile(s) in contrib tree makes this process
harder. It also seriously interacts with cross builds.
Don't also forget that most of libraries which can be
compiled in Linux can also be ported to other *nixes
I'd appreciate if you could help, as it's extremely
difficult to oversee the .rpm creation.
My changes seemed humble to me, most of them should
have kept existing functionality (in regards to
the include path stuff), the rest (header file
installation) were clear bugs in previous revisions.
I'm sorry if I'm messing up something, but this is
exactly the part, where we need to work together.
If you have any details to share, why it did fail
now, I can give a shot to correct it.
For cross-builds, we probably should have a way to
detect it. But at this moment I have no idea how
contrib cross-builds work in the GNU-make system.
(BSD, MacOSX, SunOS, HPUX, AIX, ...) and most of statements
like:
ifeq ($(HB_ARCHITECTURE),linux)
should be updated for this systems, too.
These modification also make adding autoconf support much
harder because now I will have to add support for it into
each library. It will be much easier to check dependences
and create contrib library list in one place instead of
updating each library.
I'd still insist on keeping the logic local. It must be
possible to do and the benefits are clear.
Before I started this, most contribs didn't even compile,
and rules were fully chaotic. It might have worked for
the "most important" contribs in Linux, but the goal would
be to make this flexible and not let some contribs rot
and to make them work on all OSes equally well. I'd also find
it important to close the gap between GNU and non-GNU make.
If we can make GNU flexible a properly working enough, we
might even drop the non-GNU version, which would also make
maintenance much easier and usage much clearer. Also notice
that before today's changes, each externally dependent
contrib was using a slightly unique technique to solve
these problems, and I think it would be nice to generalize
these, as the problem is the same, the solution should also
be generic.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
