bdb@cl.cam.ac.uk (Brian Brunswick) (06/04/91)
In article <&+3_98|@warwick.ac.uk> maumg@warwick.ac.uk (Pop Mobility Freak) writes: ... talks about recompiling freeze... >If you use make install a version will be copied into %.Tar because this is >where I store it for use with tar .... >A few system variables are used to find the CLib and Utils libraries and >header files. <C$LibRoot> is used to find the CLib and the Utils library is >assumed to be in <C$Loc>.Utils. To alter these locations it would be best to >edit the makefile. >However I believe we ought to come to an unoffical standard about using >operating system variables to locate libraries as everyone will want to store >the libraries in different places. This would prevent names being hardwired ..... Well..., In BRIEF, I want lib: for all libraries, nothing for C headers (i.e. assume c$libroot set up already) and install xxx to <bin$path>xxx (in lieu of bin:xxx), oh and hdr: for assembler. Details follow: I set up some path variables so that I can link with lib:o.stubs, lib:o.bdblib lib:o.utils etc, even though the libraries themselves live in separate places... Now what is really wanted is for link to default to searching there... I also use h: for C includes, hdr: for assembler etc. The trouble with the C compiler is that it does have a built in path, namely c$libroot, but its actually a directory, not a path. So my boot up does Set c$libroot <h$path>.h.^ in order to make things work since riscos lacks a current directory symbol that is usable in path. Luckily, most places with C includes contain a h subdirectory :-) Sadly, having so many variables stops dynamic updating :-( All this business with install targets is majorly irritating too. I think we need a standard for such places, like bin:, but we won't be able to use writable paths for some time.... Maybe copy thingy <bin$path>thingy F~C~WHATEVER would do... but please not things based on $ or %, since they don't work cross file systems!!!!!! (And I have 3 - adfs:, scsi: and part:, which is a partition of a scsi disk) At the moment, I develop from the desktop and the taskwindow, (got an ARM3 :->) So I usually install stuff by dragging... Unless I use my !Links thing to have the binary version point to where developement happens. But then this is only feasible when you can keep everything on line. Along these same lines, I'm very careful to have as few absolute paths around in my system as possible... in fact for command line stuff they are all localised in one boot file... I have two 100 Mb scsi file systems, and I can move stuff from one to the other or change the drive name/number, and I only have to edit this one 10 line file and all else works... Sadly this is not so good for the desktop. <StandardRantAboutAbsolutePaths> Brian.Brunswick@uk.ac.cam.cl Disclaimer. Short sig rules!