rpms/octave-forge/devel octave-forge.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2

[Michael Schwendt]

On Thu, 21 Apr 2005 14:49:08 -0500, Quentin Spencer wrote:

> Michael Schwendt wrote:
> 
> > ...
> >
> >>%build
> >>LC_ALL=POSIX
> >>export LC_ALL
> >>%define host_type %(echo "disp(octave_config_info('canonical_host_type'))" | octave -qf)
> >>%define site_dir octave/%{octave_ver}/site
> >>## The paths are hardcoded by configure, so this ugly configure command
> >>## is necessary to get them to install in the right places.
> >>./configure --with-x --prefix=$RPM_BUILD_ROOT%{_prefix} \
> >>	--mandir=$RPM_BUILD_ROOT%{_mandir} --libdir=%{_libdir} \
> >>	--with-mpath=$RPM_BUILD_ROOT%{_datadir}/%{site_dir}/m/octave-forge \
> >>	--with-opath=$RPM_BUILD_ROOT%{_libexecdir}/%{site_dir}/oct/%{host_type}/octave-forge \
> >>	--with-xpath=$RPM_BUILD_ROOT%{_libexecdir}/%{site_dir}/exec/%{host_type} \
> >>	--with-altpath=$RPM_BUILD_ROOT%{_datadir}/%{site_dir}/octave-forge-alternative/m \
> >>	--with-altmpath=$RPM_BUILD_ROOT%{_datadir}/%{site_dir}/octave-forge-alternative/m/octave-forge \
> >>	--with-altopath=$RPM_BUILD_ROOT%{_libexecdir}/%{site_dir}/octave-forge-alternative/oct/%{host_type}
> >>make %{?_smp_mflags}
> >>    
> >>
> >
> >$RPM_BUILD_ROOT at this position looks plain wrong, since it's way too
> >dangerous to increase the possibility that buildroot paths find their way
> >into the compiled binaries or any files created from *.in templates. Unless there
> >is a specific configure switch which accepts a buildroot argument, never (!) use
> >$RPM_BUILD_ROOT or %buildroot in the %build section.
> >
> >  
> >
> >>%install
> >>rm -rf $RPM_BUILD_ROOT
> >>make install 
> >>    
> >>
> >
> >Does the program not provide any way to install into a buildroot?
> >E.g. the standard "make install DESTDIR=$RPM_BUILD_ROOT"? If not, use
> >the %makeinstall macro and use the %configure macro in the %build
> >section. See /usr/lib/rpm/macros on what those two do exactly.
> >...
> >
> Thank you for looking at this. The problem is that I think the configure 
> script is not well written (though I belong to the upstream developer 
> group, I didn't write it). Some of the installation paths that it 
> generates internally become hardcoded to / and can't be relocated to 
> $RPM_BUILD_ROOT/ by make install, so to get it to install in a path with 
> an arbitrary prefix, you pretty much have to put it in the configure 
> script. I don't see any other solution to this other than patching the 
> configure script. Any other ideas? I had written these ugly spec file 
> hacks to get around the fact that I don't know my way around configure 
> scripts very well, but maybe it's time I learned.

Hmm, that's ugly and non-intuitive. Let's take an examplary look at
how the --with-altmpath parameter is passed on into the code. It's one
of the switches set in your spec file. Following "configure" script, where
"altmpath" is assigned to and then substituted in all build-time generated
files, I see this:

Makeconf.base:ALTMPATH = @altmpath@
Makeconf.in:ALTMPATH = @altmpath@
Makefile:       @echo "   ALTMPATH = $(ALTMPATH)"

extra/graceplot/grace_octave_path.m.in:    __pl_grace_octave_path = "@ALTMPATH at graceplot";


A similar thing for other paths, e.g. --with-mpath => $MPATH => $LOADPATH

In the binaries you've build, buildroot does not show up in any code
files?