To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=43310
User shay changed the following:
What |Old value |New value
================================================================================
Status|RESOLVED |REOPENED
--------------------------------------------------------------------------------
Resolution|FIXED |
--------------------------------------------------------------------------------
------- Additional comments from [EMAIL PROTECTED] Thu Apr 21 03:32:30 -0700
2005 -------
Sorry, I've just discovered another bug relating to ".a.b"'s and "::"'s, so I
thought it would be best to reopen this issue.
I stumbled across it when trying to build a perl module with dmake. Some perl
modules have access to C functions via an intermediary language called XS, and
these XS files are sometimes generated by a perl script during the build
process. This leads to a situation like the following:
.USESHELL :
.c.obj :
copy $*.c $*.obj
.xs.c :
copy $*.xs $*.c
foo.xs ::
echo foo>foo.xs
When I run "dmake foo.obj" with the above makefile I find that foo.xs is
correctly created, but then immediately deleted (something to do with the
.REMOVE recipe in startup/startup.mk, I think), which then causes the
foo.xs->foo.c copy to fail:
C:\Temp>dmake foo.obj
echo foo>foo.xs
del foo.xs
copy foo.xs foo.c
The system cannot find the file specified.
dmake: Error code 129, while making 'foo.c'
If I change the "foo.xs ::" to just "foo.xs :" then foo.xs is not deleted until
after the copy (and likewise, foo.c is not deleted until after the
foo.c->foo.obj copy), so it all works OK:
C:\Temp>dmake foo.obj
echo foo>foo.xs
copy foo.xs foo.c
1 file(s) copied.
del foo.xs
copy foo.c foo.obj
1 file(s) copied.
del foo.c
While we're on the subject, I also find that this automatic removal of the
foo.xs and foo.c files is quite undesirable. When developing perl modules in
this way, one very often wants to look at the contents of the generated .xs and
.c files, so it would be much more useful if they were left behind afterwards.
I find that the files are indeed left behind if the ".a.b"-style rules are
written out longhand, e.g.
.USESHELL :
foo.obj : foo.c
copy foo.c foo.obj
foo.c : foo.xs
copy foo.xs foo.c
foo.xs ::
echo foo>foo.xs
Running the above works fine, and leaves foo.xs and foo.c:
C:\Temp>dmake -f makefile-explicit.mk foo.obj
echo foo>foo.xs
copy foo.xs foo.c
1 file(s) copied.
copy foo.c foo.obj
1 file(s) copied.
Is this difference between ".c.obj :" and "foo.obj : foo.c" intentional? I must
admit that I did not understand the manual's description of exactly which
targets are deleted by .REMOVE, namely those that "result from the application
of transitive closure on the dependency graph." (!)
(I note that adding .PRECIOUS to ".c.obj" and ".xs.c" also stops the .c and .xs
files from being deleted.)
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
