[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Making gnustep libs in a buildroot
Re: Making gnustep libs in a buildroot
Fri, 10 May 2002 13:47:34 +0100
Thanks for your reply. You've basically answered the questions, but brought
up a few more...
On Friday 10 May 2002 13:12, you wrote:
> > Hi,
> > I'm wondering if there is support in gnustep makefiles for the following:
> > I want to be able to make an rpm containing several different GNUstep
> > libraries, all but one of them dependent on that one.
> > In general with RPMs you go through a build stage first, then an install
> > stage, where the install can go into an installation root.
> > I would like to prevent the libraries I am building from depending on my
> > currently installed set of "live" libraries, and only depend on / link to
> > the ones that are being built at the same time.
> > I presume this means I am going to have to build the first one, install
> > it into the installroot, then build the second one, telling it to use a
> > -L and -I path of the installroot.
> > What flags can I use for make to achieve this?
> > Ideally I'd like to be able to do all the builds in a oner, then all the
> > installs, so is there support for make to be given a library/header
> > search path for a not-yet-installed library?
> ... but the first question I would ask you is - ignoring RPMs for now -
> can you build all of your libraries on a clean system with a single
> top-level 'make' command ?
> If you can't, then you need to fix that first. :-)
That's part of the problem. The first lib is in package 'A', the second in
package 'B', and the third and fourth in 'A'. Each depends on all the ones
> Fixing that requires adding -I and -L flags so that the not-yet-installed
> libraries are found.
> For example, say that you have
> ./Stephen/xxx [first library]
> ./Brandon/xxx [second library prelinked against the first one]
> In the top level GNUmakefile, you list Stephen before Brandon (so it's
> compiled before the other library).
> In Stephen/GNUmakefile, you simply compile libStephen.
> In Brandon/GNUmakefile, you simply compile libBrandon, but adding
> libBrandon_INCLUDE_DIRS += -I../
> libBrandon_LIB_DIRS += -L../Stephen/obj/
aha, that's useful - I had not noticed the symlink from obj to
> libBrandon_LIBRARIES_DEPEND_UPON += -lStephen
> (assuming headers of Stephen are accessed as in #include
> "Stephen/Stephen.h") [warning/disclaimer - untested: typos in the exact
> variable names likely ;-)]
That's another part of the problem -- the directory names are not always the
same as the installed library names. Example:
package 1 is MKPerformSndMIDI
it's located as
That is because we have several versions of the library (framework) for
> Then, compiling on a clean system should work with a single 'make' at the
> top-level. Try and hack till that works reliably :-)
groan. Big reorganisation :-( But I think we do need to do it.
> Once this is done, I think making an RPM out of all the libraries at once,
> using the default gnustep-make support for RPM should automatically work
> out of the box (or your own hand-made support, it doesn't matter).
Are you saying that by having a single top-level makefile (aggregate
project?), this would put the two lower-level libraries into the one rpm? If
so that's pretty cool, but I didn't think that was going to be possible.
What I am wondering about doing is this:
- the %prep section of the spec file sticks the sources in:
/usr/src/redhat/BUILD/MusicKit-5.5.0 and /usr/src/redhat/BUILD/MusicKit-2.3.0
- in the %build section, I do a normal build for MKPerformSndMIDI, then do a
make install into a secondary installroot.
- still within %build, for the second package (in SndKit-2.3.0) I do this:
- in the %install section I do a fairly normal install into the official
A wee bit of a hack, but takes care of the -L and -I without having to do a