Re: Making gnustep libs in a buildroot

[Stephen Brandon]

Hi Nicola,

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 
before it.

> Fixing that requires adding -I and -L flags so that the not-yet-installed
> libraries are found.
>
> For example, say that you have
>
> ./GNUmakefile
>
> ./Stephen/GNUmakefile
> ./Stephen/xxx [first library]
>
> ./Brandon/GNUmakefile
> ./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 
shared_obj/ix86/.......

> 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 
MusicKit/Frameworks/PlatformDependant/MKPerformSndMIDI_portaudio(/ *.[hm])

That is because we have several versions of the library (framework) for 
different platforms.

> 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:
ADDITIONAL_INCLUDE_DIRS=-I/var/tmp/MK-buildroot/usr/GNUstep/Local/Headers \ 
ADDITIONAL_LIB_DIRS=-L/usr/src/redhat/BUILD/MusicKit-5.5.0/....../obj \
 make

- in the %install section I do a fairly normal install into the official 
installroot

A wee bit of a hack, but takes care of the -L and -I without having to do a 
complete re-organisation.

Cheers,
Stephen