In message <dub120-ds14efbda43cca2a66edd32bf0...@phx.gbl>
"Alan Buckley" <alan_...@hotmail.com> wrote:
> Ron wrote on Sent: Monday, Oct 07, 2013 1:32 AM:
>
> > I now think that putting a lib such as libOSLib.a in SharedLibs is only
> > appropriate if nonstatic output is required. A better place for added
> > libraries seems to be in !GCC.arm-unknown-riscos.lib and then there is
> > no need for -LOSLib: and setvars at all.
> > A nice touch would be to have a !StaticLibs app (Sprite etc) inside
> > !GCC that simply filer_open 's the dir so there is no future confusion
> > to placement and as a reminder to take them forward when renewing !GCC.
> > I think this was the attraction to use !SharedLibs in the first place,
> > (one familiar place for libraries)
>
> > Libraries are also found in !GCC.libs, but on the same level,
> > !GCC.include is no good for finding oslib/xxx.h so I'm going with
> > !GCC.arm_unknown_riscos.
> > By putting the oslib directory of h/HDR's in
> > !GCC.arm-unknown-riscos.include
> > They are found either with <oslib/xx.h> or "oslib/xx.h" and once again,
> > no setvars required. Some oslib .h files reference other oslib files
> > with "oslib/xxh" so it is necessary for that form to work also, but
> > there wont be an error from using <oslib/xx.h> either so its a win win.
>
> > I'm not saying that the packaged method for installing oslib wont work,
> > I just think what I have described will be simpler across the board
> > and there is less to do/go wrong in the Makefile or gcc commands.
>
> > Cheers Ron M.
>
> The problem with OSLib is that there are several versions for
> different compile options (e.g. module, soft-float etc) and it
> is set up with them all having the same name so the correct
> one does currently need to be selected with an Obey file as
> you can't copy them all into the same directory.
>
> Although I could be convinced otherwise, I do like the way
> RISC OS libraries are set up much like applications with
> the include, library and documentation in the same
> place. I've never found it too much of a problem to ensure
> they are booted, but I can see how that is an extra step.
> One thing about using application directories I have found
> useful is being able to double-click on them so I can select
> a particular version.
>
I see your point,and the setvars/path would allow each version
to be in an identifying directory.
An initially more complex way would be for an app or !confix
frontend to rename the required directory so it is found.
Each oslib directory would have an obey file that could be
run to reverse the process, giving it back an identifying
name.
The dot a files would need a copy with force from their
extended identifying name., As they are not in a directory
and I dont think gcc recurses down a lib directory.
One plus for renaming would be that once configured they
would be solidly in place and stay correct from any entry
point to gcc and after rebooting.
The Obey/setrvars method could use Choices: for permanence as
an alternative as long as it is run each time.
Personally I have more than enough to do just learning to
put oslib to use, without worrying about hardfloat.
Cheers Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
