>
> Simon Wood writes:
> >
> > I've been getting a few emails wanting/offering help with ELKSibo (i.e. on
> > the Psion Series 3). These have basically prompted me to get on with doing
> > some more. I had a play last night and have a few questions/ideas to throw
> > at the group - please bear with me.
> >
> > 1). I have modified the /arch/psion tree to refer to the /arch/i86 tree
> > where there are not changes. This is easy for whole directories
> > /arch/i86/lib, but more difficult for thing like /arch/psion/kernel which
> > has a mix of new and old.
> > I tried just referring to the files as ../../i86/kernel/signal.c but the
> > problem came when generating dependencies as the '.c' weren't local to the
> > makefile. At present I have used symbolic links to the files to overcome
> > this.
> > Any suggestions, as I believe sym-links are a no no..?
That's what the VPATH variable is for. You set VPATH to the location of your
source files and it properly checks dependencies.
If you have a single source tree, with ifdefs, and you want to build 2 target
platform binaries, you would make a Makefile for each, with the appropriate
defines, then run a build, the VPATH will find the source and build the binaries
wherever the Makefile is.
> >
> > (Al I'll send you a copy directly in the next couple of days....)
>
> I am sorry, this is my fault for failing to communicate properly, but I
> have re-organised the code so that there is not need for the arch/psion
> directory. I have got the code to the point where it compiles cleanly
> to produce an 8086 version of the kernel. I have not yet tested the sibo
> build.
>
> I have thought about this alot, and tried various ways of aproaching the
> problem, and this is in my opinion the best. It makes it much easier to
> make changes to the code, keeping both version in sync. The only files
> that are so different that separate version are required for the sibo
> kernel are crt0.S, crt1.c and irqtab.c, so these sit in a directory
> called arch/i86/sibo. Symlinks are impossible because CVS won't manage them
> properlly, and rules which refer to files on other directories make for a
> very messy build process, and no devent deps.
>
> Releasing this code has been delayed because CVS was down, and I could
> not face merging the code by hand. I will check the code in today, and do
> a snapshot release, then merge it into the main branch if you are happy.
>
> The work I have put in merging the sibo code with the changes made to the
> low level code to accomodate booting from ROM were pretty hairy, and I
> am now confident it is stable.
>
> Al
>
--
Perry Harrington Linux rules all OSes. APSoft ()
email: [EMAIL PROTECTED] Think Blue. /\
