guile-snarf writes to $srcdir, which is not kosher

guile-snarf writes to $srcdir, which is not kosher

[Marius Vollmer]

Sigh, I've seen this coming...

guile-snarf writes its $cleanfile into the $srcdir, which is not a
supported thing to do during a VPATH build.

(This was uncovered by a simple "make distcheck", which thankfully
write-protects the source directory.  I hope everybody uses "make
distcheck" freely before checking in their changes, eh?)

It could either write the files into the build dir (which would be
difficult to do, when we want to support snarfing files that are not
in the current $srcdir), or it could stop trying to clean the input
altogether.

I'm in favor of the latter option since the cleaning is too much of a
kluge in my view.  It does appear to do the right thing, but only in a
situation where it is not needed: when someone snarfes directly to a
file (using "-o foo.x").  But in this case, the output file will
already exist, with a safe content, when the pre-processor is run
(modulo some theoretical buffering issues that are not going to
appear).  People who do not use "-o" always needed and still need to
protect against non existing .x files.  They can do that with the
(now) supported SCM_MAGIC_SNARFER macro.

This is bug "guile-snarf-writes-to-srcdir".

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-snarf writes to $srcdir, which is not kosher

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 08 Apr 2002 00:55:38 +0200

   Sigh, I've seen this coming...

   guile-snarf writes its $cleanfile into the $srcdir, which is not a
   supported thing to do during a VPATH build.

looks like some coding cowboy should've figured out what kind of builds
are to be supported before doing this kind of thing.  (sorry for that.)
what is a "VPATH build", specifically?  what other kinds of builds are
there?

   (This was uncovered by a simple "make distcheck", which thankfully
   write-protects the source directory.  I hope everybody uses "make
   distcheck" freely before checking in their changes, eh?)

you can do more than hope: why not write down some good tips under
workbook/build/ somewhere?

   [cleaning not required in the presence of SCM_MAGIC_SNARFER]

if you remove cleaning you need to promote SCM_MAGIC_SNARFER to required
status and document accordingly.

thi

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-snarf writes to $srcdir, which is not kosher

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> what is a "VPATH build", specifically?

A VPATH build is when you compile in a directory other than the source
directory.  This is useful when you want to compile a package for
different configurations but from a common source.  The name stems
from the fact that it is implemented using the VPATH variable of make.

> what other kinds of builds are there?

I only about VPATH builds and 'normal' builds where the object files
end up in the same directory as the source.

>    (This was uncovered by a simple "make distcheck", which thankfully
>    write-protects the source directory.  I hope everybody uses "make
>    distcheck" freely before checking in their changes, eh?)
> 
> you can do more than hope: why not write down some good tips under
> workbook/build/ somewhere?

Ok, it's in HACKING.

>    [cleaning not required in the presence of SCM_MAGIC_SNARFER]
> 
> if you remove cleaning you need to promote SCM_MAGIC_SNARFER to required
> status and document accordingly.

It is already.

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-snarf writes to $srcdir, which is not kosher

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 08 Apr 2002 18:45:44 +0200

   A VPATH build is when you compile in a directory other than the source
   directory.  This is useful when you want to compile a package for
   different configurations but from a common source.  The name stems
   from the fact that it is implemented using the VPATH variable of make.

could you describe VPATH as "configure in place, make from elsewhere"?
or is configure done elsewhere also?  i've heard the latter referred to
as srcdir!=builddir (and usually make is done where configure is).

   > if you remove cleaning you need to promote SCM_MAGIC_SNARFER to required
   > status and document accordingly.

   It is already.

all i see is this:

  During snarfing, the pre-processor macro @code{SCM_MAGIC_SNARFER} is
  defined.

i'm assuming that whatever changes made to branch_release-1-6 that are
long-term applicable would be also made in HEAD roughly concurrently,
but i guess this is saved for later?

thi

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-snarf writes to $srcdir, which is not kosher

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    A VPATH build is when you compile in a directory other than the source
>    directory.  This is useful when you want to compile a package for
>    different configurations but from a common source.  The name stems
>    from the fact that it is implemented using the VPATH variable of make.
> 
> could you describe VPATH as "configure in place, make from elsewhere"?
> or is configure done elsewhere also?

configure is run elsewhere also, in the same location as make.

> i've heard the latter referred to as srcdir!=builddir (and usually
> make is done where configure is).

Right, that's the one.  I know it by the name of "VPATH build" which I
admit is a quite obscure name.

> all i see is this:
> 
>   During snarfing, the pre-processor macro @code{SCM_MAGIC_SNARFER} is
>   defined.

Right.  I agree that this is a bit thin.  I have added more text to
make the intention clear.

> i'm assuming that whatever changes made to branch_release-1-6 that are
> long-term applicable would be also made in HEAD roughly concurrently,
> but i guess this is saved for later?

Yes, I was only concernd about getting 1.6 into working order, make it
compatible with guile-snarf from 1.4, and having it not offer
interface features that are likely to be redesigned.  I'm totally open
as to what will happen for 1.8, so I didn't change it there as well.

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-snarf writes to $srcdir, which is not kosher

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 09 Apr 2002 19:03:29 +0200

   I'm totally open as to what will happen for 1.8, so I didn't change
   it there as well.

ok, noted in TODO.

thi

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-snarf writes to $srcdir, which is not kosher

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    From: Marius Vollmer <mvo@zagadka.ping.de>
>    Date: 08 Apr 2002 18:45:44 +0200
>
>    A VPATH build is when you compile in a directory other than the source
>    directory.  This is useful when you want to compile a package for
>    different configurations but from a common source.  The name stems
>    from the fact that it is implemented using the VPATH variable of make.
>
> could you describe VPATH as "configure in place, make from elsewhere"?
> or is configure done elsewhere also?  i've heard the latter referred to
> as srcdir!=builddir (and usually make is done where configure is).

Check out the "Compiling For Multiple Architectures" node in
autoconf's info pages -- it explains the process at least...

> i'm assuming that whatever changes made to branch_release-1-6 that are
> long-term applicable would be also made in HEAD roughly concurrently,
> but i guess this is saved for later?

I've been trying to make sure to migrate all my 1.6 patches to HEAD,
but there are still some outstanding.  Of course some of the lag is
because I'm not sure we'll want to handle things the same in 1.8.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-snarf writes to $srcdir, which is not kosher

[Thien-Thi Nguyen]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Wed, 10 Apr 2002 16:10:56 -0500

   I've been trying to make sure to migrate all my 1.6 patches to HEAD,
   but there are still some outstanding.  Of course some of the lag is
   because I'm not sure we'll want to handle things the same in 1.8.

hmmm, this is very different way of looking at things from what i would
expect...  i'm operating on the assumption that we want to look at
things from long-term perspective first and foremost, and interpolate
current decisions/activities from that.  that is, figure out LATER and
then figure out NOW as it relates to LATER, rather than the reverse.

in practice, this means changing HEAD branch to conform to LATER first,
and branch_release-1-6 to conform to NOW.  to me this seems like less
work.

thi

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-snarf writes to $srcdir, which is not kosher

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> in practice, this means changing HEAD branch to conform to LATER first,
> and branch_release-1-6 to conform to NOW.  to me this seems like less
> work.

Depends on the problem.  For example, the recent library name changes
relating to libltdl/dlopen issues may or may not belong in HEAD, but
they're critical for 1.6.

Since it's very likely we'll choose a different long-term solution for
this problem, and we won't know until we have the discussion, in my
judgement there was little point in trying to integrate the changes
into HEAD right now.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-snarf writes to $srcdir, which is not kosher

[Thien-Thi Nguyen]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Tue, 23 Apr 2002 17:42:58 -0500

   Depends on the problem.  For example, the recent library name changes
   relating to libltdl/dlopen issues may or may not belong in HEAD, but
   they're critical for 1.6.

the recent changes may or may not belong in HEAD but the questions i'm
asking are: (1) what *does* belong in HEAD?
	    (2) how does the 1.6 library handling relate to (1)?

   Since it's very likely we'll choose a different long-term solution
   for this problem, and we won't know until we have the discussion, in
   my judgement there was little point in trying to integrate the
   changes into HEAD right now.

of course these things follow.  i'm not questioning the consequence of
the approach, but the wisdom of using that approach in the first place,
which seems backwards and make-work-ful to me.

thi

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-snarf writes to $srcdir, which is not kosher

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> of course these things follow.  i'm not questioning the consequence of
> the approach, but the wisdom of using that approach in the first place,
> which seems backwards and make-work-ful to me.

Well I wasn't implying it's how you'd want to do everything, or even
most things, just mentioning in passing that there were *some* things
that I'd done that way.  Might have been better if I hadn't said
anything.

Furthermore, as I've said several times before, I consider 1.6 a
special case -- it has taken too long to get out the door, and as such
there's been more divergence between the 1.6 branch and HEAD than
anyone would like.  While I'm trying to make sure we set things up so
that's less likely to happen again, it *has* happened.  As a result,
changes for one side may not apply as easily as we'd like to the other
side.  This means that when I need to make changes that I *know* have
to go into 1.6, but probably aren't appropriate (in the same form) for
HEAD, I may in fact just write them for 1.6 and then see if they
can/should be trivially ported to HEAD.  If not, then I make a note of
the pending to-do item for 1.8.  In some cases, coming up with a fix
for HEAD as well right now would likely be a waste of time.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: guile-snarf writes to $srcdir, which is not kosher

[Thien-Thi Nguyen]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Tue, 23 Apr 2002 18:09:04 -0500

   Furthermore, as I've said several times before,

this should give you a clue that saying things on mailing lists isn't as
useful to other people understanding you, as writing them down somewhere
under workbook/ and inviting review and refinement there.

   [...]

what are the areas of divergence?  why not add an item for each (as in
"port foo to HEAD") to TODO?  this would help us understand things more
precisely.

thi

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile