* [parisc-linux] new method for 64-bit parisc tree
@ 2000-11-01 17:59 Paul Bame
2000-11-02 8:51 ` Alan Modra
2000-11-07 18:15 ` [parisc-linux] 64-bit BUILD CHANGES Paul Bame
0 siblings, 2 replies; 4+ messages in thread
From: Paul Bame @ 2000-11-01 17:59 UTC (permalink / raw)
To: parisc-linux
I want to propose/discuss a new method for maintaining our 64-bit parisc
tree in relation to the 32-bit tree. I have prototyped this and so
far it seems pretty useful.
Most of the files in the current parisc64 tree only contain one
line, a #include of the same file from the parisc tree. This confuses
'make dep', causes some compile errors to have nonsense line numbers,
and doesn't allow direct editing of the source files in the parisc64 tree.
The method I'm proposing works like this:
The future parisc64 tree ONLY contains files which are different from,
or in addition to, those in the parisc tree. When you 'make config'
or 'make oldconfig', each file in the parsic tree is symbolically
linked as the same file in the parisc64 tree. This enables all
the rest of the tools/build to work normally. 'make distclean' includes
a step to remove all the symlinks.
The ugliest "feature" is that even though you can edit source files
in the parisc64 tree, 'cvs commit' will fail on those which are
symbolic links. To reduce this problem, I'm dropping a symbolic link
called '...' in each parisc64 directory which is a pointer to the
corresponding parisc directory, so 'cd ...; cvs commit foo.c' will
work and not be too onerous.
We should additionally consider a naming convention or something so
that maintainers in the parisc tree know whether files are shared with
parisc64 or not.
I prototyped this as a fictional new "architecture" called "p64". To
try it out, grab the tarball (only about 30 files -- can be fewer)
ftp://puffin.external.hp.com/pub/parisc/
and unpack in your top-level linux source tree directory. Then in
your top-level Makefile, change ARCH := parisc64 to ARCH := p64, then
make oldconfig or whatever you usually do. Let me know of any problems.
Is this something we should adopt for the real parisc64 tree?
-Paul Bame
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [parisc-linux] new method for 64-bit parisc tree
2000-11-01 17:59 [parisc-linux] new method for 64-bit parisc tree Paul Bame
@ 2000-11-02 8:51 ` Alan Modra
2000-11-02 16:20 ` bame
2000-11-07 18:15 ` [parisc-linux] 64-bit BUILD CHANGES Paul Bame
1 sibling, 1 reply; 4+ messages in thread
From: Alan Modra @ 2000-11-02 8:51 UTC (permalink / raw)
To: Paul Bame; +Cc: parisc-linux
On Wed, 1 Nov 2000, Paul Bame wrote:
> The future parisc64 tree ONLY contains files which are different from,
> or in addition to, those in the parisc tree. When you 'make config'
> or 'make oldconfig', each file in the parsic tree is symbolically
> linked as the same file in the parisc64 tree. This enables all
> the rest of the tools/build to work normally. 'make distclean' includes
> a step to remove all the symlinks.
Instead, can't you simply play tricks with -I, and add a symbolic link
asm -> ../asm-parisc in asm-parisc64)? The idea being to end up with
an include path looking like
"-I $(TOPDIR)/include -I $(TOPDIR)/include/asm"
That way, asm/foo.h is found by the first -I if we have asm-parisc64/foo.h,
and is found by the second if asm-parisc/foo.h exists but not
asm-parisc64/foo.h. Hmm, you might also need -I-
--
Linuxcare. Support for the Revolution.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [parisc-linux] new method for 64-bit parisc tree
2000-11-02 8:51 ` Alan Modra
@ 2000-11-02 16:20 ` bame
0 siblings, 0 replies; 4+ messages in thread
From: bame @ 2000-11-02 16:20 UTC (permalink / raw)
To: Alan Modra; +Cc: parisc-linux
I want to hear concerns because without serious ones I'm going to
make this change next week...
= Instead, can't you simply play tricks with -I, and add a symbolic link
= asm -> ../asm-parisc in asm-parisc64)? The idea being to end up with
= an include path looking like
= "-I $(TOPDIR)/include -I $(TOPDIR)/include/asm"
=
= That way, asm/foo.h is found by the first -I if we have asm-parisc64/foo.h,
= and is found by the second if asm-parisc/foo.h exists but not
= asm-parisc64/foo.h. Hmm, you might also need -I-
That would function fine for header files, but not for source files
where something like VPATH might work, but is not available to us. It's
worth noting that both -I and VPATH tricks mean if you have an error
in or need to change a file, you may have to examine two
directories to figure out where it really lives. The symbolic link
scheme solves some of that problem.
-P
^ permalink raw reply [flat|nested] 4+ messages in thread
* [parisc-linux] 64-bit BUILD CHANGES
2000-11-01 17:59 [parisc-linux] new method for 64-bit parisc tree Paul Bame
2000-11-02 8:51 ` Alan Modra
@ 2000-11-07 18:15 ` Paul Bame
1 sibling, 0 replies; 4+ messages in thread
From: Paul Bame @ 2000-11-07 18:15 UTC (permalink / raw)
Cc: parisc-linux
The described changes have just been committed to CVS. If you have
an existing configured/built 64-bit parisc tree right now I think these
are the steps to update:
Save your .config file
do 'make distclean'
do your cvs update
restore your .config
make oldconfig dep
and then proceed as normal
The symlinks come when you do a make {old}config and
go with a 'make distclean' FYI
>>> You may want to start hand-editing .hdepend (following each make dep)
to remove the dependency of atomic.h on spinlock.h (just remove the first
line containing the string spinlock.h) -- it can cause massive
unnecessary rebuilds. It's due to a parisc-specific circular dependency :-(
-P
= I want to propose/discuss a new method for maintaining our 64-bit parisc
= tree in relation to the 32-bit tree. I have prototyped this and so
= far it seems pretty useful.
=
= Most of the files in the current parisc64 tree only contain one
= line, a #include of the same file from the parisc tree. This confuses
= 'make dep', causes some compile errors to have nonsense line numbers,
= and doesn't allow direct editing of the source files in the parisc64 tree.
=
= The method I'm proposing works like this:
=
= The future parisc64 tree ONLY contains files which are different from,
= or in addition to, those in the parisc tree. When you 'make config'
= or 'make oldconfig', each file in the parsic tree is symbolically
= linked as the same file in the parisc64 tree. This enables all
= the rest of the tools/build to work normally. 'make distclean' includes
= a step to remove all the symlinks.
=
= The ugliest "feature" is that even though you can edit source files
= in the parisc64 tree, 'cvs commit' will fail on those which are
= symbolic links. To reduce this problem, I'm dropping a symbolic link
= called '...' in each parisc64 directory which is a pointer to the
= corresponding parisc directory, so 'cd ...; cvs commit foo.c' will
= work and not be too onerous.
=
= We should additionally consider a naming convention or something so
= that maintainers in the parisc tree know whether files are shared with
= parisc64 or not.
=
= I prototyped this as a fictional new "architecture" called "p64". To
= try it out, grab the tarball (only about 30 files -- can be fewer)
= ftp://puffin.external.hp.com/pub/parisc/
= and unpack in your top-level linux source tree directory. Then in
= your top-level Makefile, change ARCH := parisc64 to ARCH := p64, then
= make oldconfig or whatever you usually do. Let me know of any problems.
=
= Is this something we should adopt for the real parisc64 tree?
=
= -Paul Bame
=
= ---------------------------------------------------------------------------
= To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
= `unsubscribe' as the subject.
=
=
=
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2000-11-07 18:14 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-11-01 17:59 [parisc-linux] new method for 64-bit parisc tree Paul Bame
2000-11-02 8:51 ` Alan Modra
2000-11-02 16:20 ` bame
2000-11-07 18:15 ` [parisc-linux] 64-bit BUILD CHANGES Paul Bame
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox