cvs commit: parrot/config/gen/makefiles root.in
Juergen Boemmels
> JüRgen" "BöMmels <boem...@cvs.perl.org> wrote:
> > +TOUCH = $(PERL) -e ${PQ}open(A,qq{>>$$_}) or die foreach @ARGV${PQ}
>
> Well done. *But* this f*cking command does still not update time stamps.
>
> Is this a Perl5 failure? Anyway, we need a (golfy) touch equivalent for
> these poor systems not providing one.
Appending nothing is not a modification (on Linux). Try this:
cat /dev/null >> imcc.flag
mtime does not change.
How about this? Its from perldoc -f utime:
TOUCH = $(PERL) -e ${PQ}$now = time; utime $now, $now, @ARGV;${PQ}
I don't know if it works reliable on Windows.
bye
boe
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Leopold Toetsch
> +TOUCH = $(PERL) -e ${PQ}open(A,qq{>>$$_}) or die foreach @ARGV${PQ}
Well done. *But* this f*cking command does still not update time stamps.
Is this a Perl5 failure? Anyway, we need a (golfy) touch equivalent for
these poor systems not providing one.
leo
Leopold Toetsch
> How about this? Its from perldoc -f utime:
Ah thanks. I should have read that first :)
> TOUCH = $(PERL) -e ${PQ}$now = time; utime $now, $now, @ARGV;${PQ}
s/\$now/\$\$now/g for Makefile's sake.
Touches existing files fine. For imcc.y.flag we could just add a create
rule, if it doesn't exist.
> I don't know if it works reliable on Windows.
That's the question. *I* don't need $(TOUCH) on linux :)
> bye
> boe
Thanks,
leo
Andy Dougherty
I can think of one other potential problem: What if the user wants to
mount the source read-only? Last I checked, except for this issue, it was
possible to do so. For perl5, this ability was often requested.
--
Andy Dougherty doug...@lafayette.edu
Leopold Toetsch
> I can think of one other potential problem: What if the user wants to
> mount the source read-only? Last I checked, except for this issue, it was
> possible to do so. For perl5, this ability was often requested.
We are generating all kinds of files inside the parrot directory. I
don't know, what you mean with "mount the source read-only". If you
mean, the filesystem, where the parrot source is on, you can't build
it.
leo
Andy Dougherty
Sorry, I guess I should have been more explicit. What folks apparently do
is have the sources on an NFS server mounted read-only. They then build a
symlink tree onto a local read-write filesystem and run the build there.
Thus they can create all the new files they want, but they can't touch or
change the source files. This is presumably helpful because other users
may be simultaneously mounting those same source files and may be
expecting them to remain unchanged from the distributed version.
perl5's build system is supposed to support this in two ways: First,
Configure contains code to detect when it's being run from a different
directory than that which contains the source. The Makefiles are supposed
to then do the right thing. I haven't touched that stuff in a long time,
and it would surprise me if it actually worked. Second, perl5's Configure
supports a -Dmksymlinks option which makes the symlink tree for you.
These features were added as a result of a number of user requests. I
vaguely recall it showing up in the archives under the description of
"self-modifying source". I have since found it useful and have used the
-Dmksymlinks feature regularly to test builds on multiple architectures
(or with different options).
--
Andy Dougherty doug...@lafayette.edu
Jeff Clites
As an extension of this, I think it would be useful to have a "build"
directory (configurable, defaulting to a "build" subdirectory of the
distro root) as a location for all intermediate (*.o, etc.) and
generated files to live. That's even simpler than a symlink tree, and
in addition to allowing read-only source has some other nice features:
you can "make clean" by deleting a single dir, and you can grep the
sources easily without having to take steps to avoid the generated
files. I've found this sort of thing useful in the context of other
projects.
JEff
Leopold Toetsch
> Sorry, I guess I should have been more explicit. What folks apparently do
> is have the sources on an NFS server mounted read-only. They then build a
> symlink tree onto a local read-write filesystem and run the build there.
> Thus they can create all the new files they want, but they can't touch or
> change the source files.
That works except for the imc{parser,lexer} generated files. But we
could remove touching these files. When Configure.pl --maintainer was
run, you probably have the tools to create these files.
leo
Dan Sugalski
Woohoo, yay delegation! :)
Seriously, I think this is a fine idea (building entirely outside the
source tree, or using a symlink nest with all the base source files
read-only) and I expect we're going to get requests for it, so we
might as well handle it now.
I'm assuming that Andy's not got sufficient time to make this happen,
so if other folks are willing to step up that'd be great.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Juergen Boemmels
Some different idea:
Rename imc{parser,lexer}.[ch] files in CVS to
imc{parser,lexer}_c.generated. In non--maintainer mode these files are
simply copied, wheras in --maintainer mode the files are regenerated
from the sources imcc.[ly]. I think gcc uses something similar.
I don't think we even need to preserve the history
imc{parser,lexer}.[ch]; they are generated files anyway.