Hi, Tim, Maurik et al,
you observe correctly that the suggested new Makefile.in scheme can live
side by side (for now) with the old Makefile scheme. As long as people
don't run configure the old Makefile will still be ok. (This is what I
had said in my first write-up.)
It is also true that the Makefile.in is similar to the old Makefile.
There is also a Makefile.inc.in, which is turned into Makefile.inc,
and this was supposed to contain the machine-specific settings
(paths, compiler and linker flags, root flags, etc.) I mentioned that
the present setup is just a demo version, so it might look like just
an "added layer of complexity", but even in this diminished form,
it gives you freedom to separate directories for compilation
and installation. Of course a half of the work still needs to be
done, so that configure will "catch" the correct stuff and squeeze
it into Makefiles. I appealed to everybody to help with that.
Although it is nothing insurmountable I could not make myself,
I thought that the people who were most closely involved with a
particular part of the software, would be most familiar with
outstanding compilation problems on different architectures,
and would do it most efficiently. But I can have a look myself
if nobody is willing to do it.
Concerning Tim's specific questions:
> First off, from you email I understand that if I want to change a
> makefile, I edit Makefile.in and NOT Makefile (because configure
> will generate a new one of these?)
Absolutely correct.
> Secondly, the present Makefiles create the libBlast.so,
> nsed, blast, etc. .. in the source directories, and do not
> move them to the run directory. To move them one needs to do a
> make install
Absolutely correct.
> On campus this will move libBlast.so into /usr/local/lib
> and nsed, s, etc.. into /usr/local/bin
> at Bates this fails becasue users do not have write permission there.
> But if, when I configure I type configure --prefix=/home/blast/tps/cvs/run
> then libBlast.so ends up in /home/blast/tps/cvs/run/lib and nsed in
> /home/blast/tps/cvs/run/bin
> Whereas this might really be a very good solution, it is not
> what people expect - they are looking for someing in the run
> directory.
The idea is not that people EXPECT a program in a certain place.
The idea is that people put the program wherever they WANT it to be.
If someone can not write into /usr/local, one should specify a
different prefix. The default lib and bin directories can be
overriden in configure even now, in this "minimal" version.
(Just hit configure --help).
Simon
-- Simon Sirca MIT-LNS, Room 26-402 Tel: +1 617 258-5438 77 Massachusetts Avenue Fax: +1 617 452-5950 Cambridge, MA 02139-4307, USA URL: http://pierre.mit.edu/~sirca
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:28 EST