* libjava build failure with read-only source tree
@ 2011-09-29 8:18 Jan Beulich
2011-09-29 8:40 ` Bryce McKinlay
2011-09-29 9:32 ` Bryce McKinlay
0 siblings, 2 replies; 6+ messages in thread
From: Jan Beulich @ 2011-09-29 8:18 UTC (permalink / raw)
To: java
When the source tree (including its directories) is read-only I get
rm: cannot remove `asm/org/objectweb/asm/xml/ASMContentHandler$LineNumberRule.class': Permission denied
rm: cannot remove `asm/org/objectweb/asm/xml/ASMContentHandler$ExceptionsRule.class': Permission denied
... (hundreds of similar messages)
rm: cannot remove `classes/sun/rmi/rmic/messages.properties': Permission denied
rm: cannot remove `classes/sun/rmi/rmic/Messages.class': Permission denied
make[4]: *** [tools.zip] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-target-libjava] Error 2
as an obvious result of using
cp -pR $(srcdir)/asm .
cp -pR $(srcdir)/classes .
in the commands of the $(TOOLS_ZIP) rule.
This is the change I'm currently checking whether it will overcome the
problem:
--- a/libjava/classpath/tools/Makefile.am
+++ b/libjava/classpath/tools/Makefile.am
@@ -371,6 +371,7 @@ endif
## BEGIN GCJ LOCAL
cp -pR $(srcdir)/asm .
cp -pR $(srcdir)/classes .
+ find asm classes -type d -exec chmod u+w \{\} \;
if [ -d asm/.svn ]; then \
find asm classes -depth -type d -name .svn -exec rm -rf \{\} \;; \
fi
As this isn't the first time I encounter this in the libjava subtree, can it
be made a requirement for testing changes that they must work with
fully read-only source trees? And/or if there's some sort of automatic
testing in place, could that be adjusted to include a respective check?
Regards, Jan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libjava build failure with read-only source tree
2011-09-29 8:18 libjava build failure with read-only source tree Jan Beulich
@ 2011-09-29 8:40 ` Bryce McKinlay
2011-09-29 9:06 ` Jan Beulich
2011-09-29 9:32 ` Bryce McKinlay
1 sibling, 1 reply; 6+ messages in thread
From: Bryce McKinlay @ 2011-09-29 8:40 UTC (permalink / raw)
To: Jan Beulich; +Cc: java
On Thu, Sep 29, 2011 at 9:18 AM, Jan Beulich <JBeulich@suse.com> wrote:
> As this isn't the first time I encounter this in the libjava subtree, can it
> be made a requirement for testing changes that they must work with
> fully read-only source trees? And/or if there's some sort of automatic
> testing in place, could that be adjusted to include a respective check?
It would be heavy-handed to require every contributor to test patches
with a read-only tree. We don't want to make the patch submission
process any more onerous than it already is.
Adjusting one of the automated regression testers to run its builds on
a read-only tree would probably make sense, however. There are several
regression testers operating - see the gcc-testresults list for
details.
Bryce
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libjava build failure with read-only source tree
2011-09-29 8:40 ` Bryce McKinlay
@ 2011-09-29 9:06 ` Jan Beulich
0 siblings, 0 replies; 6+ messages in thread
From: Jan Beulich @ 2011-09-29 9:06 UTC (permalink / raw)
To: Bryce McKinlay; +Cc: java
>>> On 29.09.11 at 10:39, Bryce McKinlay <bmckinlay@gmail.com> wrote:
> On Thu, Sep 29, 2011 at 9:18 AM, Jan Beulich <JBeulich@suse.com> wrote:
>
>> As this isn't the first time I encounter this in the libjava subtree, can it
>> be made a requirement for testing changes that they must work with
>> fully read-only source trees? And/or if there's some sort of automatic
>> testing in place, could that be adjusted to include a respective check?
>
> It would be heavy-handed to require every contributor to test patches
> with a read-only tree. We don't want to make the patch submission
> process any more onerous than it already is.
I certainly realize that. But this wouldn't be needed for all submissions,
just such that alter the tree layout of the build tree.
Btw., the patch that I had embedded in the original mail works, but as
there's no maintainer listed for libjava in ./MAINTAINERS I'm entirely
unclear who I would need to turn to in order to get approval to commit
this.
Jan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libjava build failure with read-only source tree
2011-09-29 8:18 libjava build failure with read-only source tree Jan Beulich
2011-09-29 8:40 ` Bryce McKinlay
@ 2011-09-29 9:32 ` Bryce McKinlay
2011-09-29 9:34 ` Andrew Haley
2011-09-29 9:48 ` Jan Beulich
1 sibling, 2 replies; 6+ messages in thread
From: Bryce McKinlay @ 2011-09-29 9:32 UTC (permalink / raw)
To: Jan Beulich; +Cc: java
On Thu, Sep 29, 2011 at 9:18 AM, Jan Beulich <JBeulich@suse.com> wrote:
> --- a/libjava/classpath/tools/Makefile.am
> +++ b/libjava/classpath/tools/Makefile.am
> @@ -371,6 +371,7 @@ endif
> ## BEGIN GCJ LOCAL
> cp -pR $(srcdir)/asm .
> cp -pR $(srcdir)/classes .
> + find asm classes -type d -exec chmod u+w \{\} \;
> if [ -d asm/.svn ]; then \
> find asm classes -depth -type d -name .svn -exec rm -rf \{\} \;; \
> fi
This patch looks fine to me, though I wonder if there is any good
reason why "cp -p" was used in the first place?
In any case, I'd say you can go ahead and check this in under the
"obvious" rule.
Bryce
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libjava build failure with read-only source tree
2011-09-29 9:32 ` Bryce McKinlay
@ 2011-09-29 9:34 ` Andrew Haley
2011-09-29 9:48 ` Jan Beulich
1 sibling, 0 replies; 6+ messages in thread
From: Andrew Haley @ 2011-09-29 9:34 UTC (permalink / raw)
To: java
On 09/29/2011 10:31 AM, Bryce McKinlay wrote:
> On Thu, Sep 29, 2011 at 9:18 AM, Jan Beulich <JBeulich@suse.com> wrote:
>
>> --- a/libjava/classpath/tools/Makefile.am
>> +++ b/libjava/classpath/tools/Makefile.am
>> @@ -371,6 +371,7 @@ endif
>> ## BEGIN GCJ LOCAL
>> cp -pR $(srcdir)/asm .
>> cp -pR $(srcdir)/classes .
>> + find asm classes -type d -exec chmod u+w \{\} \;
>> if [ -d asm/.svn ]; then \
>> find asm classes -depth -type d -name .svn -exec rm -rf \{\} \;; \
>> fi
>
> This patch looks fine to me, though I wonder if there is any good
> reason why "cp -p" was used in the first place?
>
> In any case, I'd say you can go ahead and check this in under the
> "obvious" rule.
Maybe, but I'm not sure why the files are being copied in the source
tree anyway. Unless gcj-maintainer-mode is enabled, it shouldn't
be necessary.
Andrew.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libjava build failure with read-only source tree
2011-09-29 9:32 ` Bryce McKinlay
2011-09-29 9:34 ` Andrew Haley
@ 2011-09-29 9:48 ` Jan Beulich
1 sibling, 0 replies; 6+ messages in thread
From: Jan Beulich @ 2011-09-29 9:48 UTC (permalink / raw)
To: Bryce McKinlay; +Cc: java
>>> On 29.09.11 at 11:31, Bryce McKinlay <bmckinlay@gmail.com> wrote:
> On Thu, Sep 29, 2011 at 9:18 AM, Jan Beulich <JBeulich@suse.com> wrote:
>
>> --- a/libjava/classpath/tools/Makefile.am
>> +++ b/libjava/classpath/tools/Makefile.am
>> @@ -371,6 +371,7 @@ endif
>> ## BEGIN GCJ LOCAL
>> cp -pR $(srcdir)/asm .
>> cp -pR $(srcdir)/classes .
>> + find asm classes -type d -exec chmod u+w \{\} \;
>> if [ -d asm/.svn ]; then \
>> find asm classes -depth -type d -name .svn -exec rm -rf \{\} \;; \
>> fi
>
> This patch looks fine to me, though I wonder if there is any good
> reason why "cp -p" was used in the first place?
Perhaps to retain the timestamps of the files without becoming too
system specific (i.e. dependent on cp's support of
--preserve=timestamps)?
> In any case, I'd say you can go ahead and check this in under the
> "obvious" rule.
Yeah, probably.
Thanks, Jan
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-09-29 9:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-29 8:18 libjava build failure with read-only source tree Jan Beulich
2011-09-29 8:40 ` Bryce McKinlay
2011-09-29 9:06 ` Jan Beulich
2011-09-29 9:32 ` Bryce McKinlay
2011-09-29 9:34 ` Andrew Haley
2011-09-29 9:48 ` Jan Beulich
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).