possible bug in mx/projects handling

[Doug Simon]

Hi Vasanth,

The problems you are seeing are due to the and process inside the makefiles that try to replicate the steps performed by 'mx build' to create graal.jar. The intention is to be able to build and deploy GraalVM without needing to use mx (and thus install Python). This requirement has been relaxed and now graal.jar is only built via mx. I'm pushing a change now that removes the ant call in the make files (it's replaced by a call to mx). Once you pull this change, you'll need to ensure a 'python2.7' executable is on your path. This should (touch wood) be the end of  build issues around JDK8 code.

-Doug

On Jun 18, 2013, at 5:50 PM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> wrote:

> Hi Doug,
> 
> We're still seeing this issue with the mx scripts attempting to build JDK8 packages when the configured JDK is JDK 7.  Below is the verbose output from mx build.
> 
> You can see it mentions it is excluding com.amd.sumatra from graal.jar, but then it tries to compile one of the classes in this package.
> 
> Vasanth
> 
> Excluding com.amd.sumatra from /home/tester/graalcloneinternal/graal/graal.jar (Java compliance level 1.8 required)
> Creating /home/tester/graalcloneinternal/graal/jdk1.7.0_13/product from /home/tester/Downloads/jdk1.7.0_13
> Creating VM directory in JDK7: /home/tester/graalcloneinternal/graal/jdk1.7.0_13/product/jre/lib/amd64/graal
> cd /home/tester/graalcloneinternal/graal/make; \
> 	make BUILD_FLAVOR=productgraal VM_TARGET=productgraal \
> 	  generic_buildgraal 
> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1
> 
> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files.
> 
> INFO: STRIP_POLICY=min_strip
> 
> INFO: ZIP_DEBUGINFO_FILES=0
> 
> make[1]: Entering directory `/home/tester/graalcloneinternal/graal/make'
> ANT_OPTS=-Djava.io.tmpdir='/home/tester/graalcloneinternal/graal/build/linux/tmp' JAVA_HOME='/home/tester/Downloads/jdk1.7.0_13' ant -f /home/tester/graalcloneinternal/graal/make/build-graal.xml -Dgamma.dir=/home/tester/graalcloneinternal/graal -Dshared.dir=/home/tester/graalcloneinternal/graal/build/linux/shared
> Buildfile: /home/tester/graalcloneinternal/graal/make/build-graal.xml
> 
> options:
> 
> cleanclasses:
> 
> compile:
>    [mkdir] Created dir: /home/tester/graalcloneinternal/graal/build/linux/shared/graal
>    [javac] Compiling 759 source files to /home/tester/graalcloneinternal/graal/build/linux/shared/graal
>    [javac] /home/tester/graalcloneinternal/graal/graal/com.amd.sumatra/src/com/amd/sumatra/ForEachToGraal.java:94: error: illegal start of expression
>    [javac]                 filter(p -> p.getName().equals("accept")).toArray();
>    [javac]                           ^
>    [javac] 1 error
> 
> 
> -----Original Message-----
> From: Doug Simon [mailto:doug.simon at oracle.com] 
> Sent: Monday, June 03, 2013 11:29 AM
> To: Deneau, Tom
> Cc: Venkatachalam, Vasanth; graal-dev at openjdk.java.net
> Subject: Re: possible bug in mx/projects handling
> 
> Ok, I see the problem. Pushing through a fix now. Here's the patch:
> 
> diff -r 91a1041ec905 mxtool/mx.py
> --- a/mxtool/mx.py      Sat Jun 01 20:42:22 2013 -0400
> +++ b/mxtool/mx.py      Mon Jun 03 18:07:59 2013 +0200
> @@ -1700,6 +1700,11 @@
>             try:
>                 zf = zipfile.ZipFile(tmp, 'w')
>                 for p in sorted_deps(d.deps):
> +                    # skip a  Java project if its Java compliance level is "higher" than the configured JDK
> +                    if java().javaCompliance < p.javaCompliance:
> +                        log('Excluding {0} from {2} (Java compliance level {1} required)'.format(p.name, p.javaCompliance, d.path))
> +                        continue
> +
>                     outputDir = p.output_dir()
>                     for root, _, files in os.walk(outputDir):
>                         relpath = root[len(outputDir) + 1:]
> 
> On Jun 3, 2013, at 5:31 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> 
>> Doug --
>> 
>> Did you also put your com.amd.sumatra as a dependency for graal.jar?  That is where the problem seems to arise.
>> 
>> distribution at GRAAL@path=graal.jar
>> distribution at GRAAL@dependencies=com.oracle.graal.hotspot.amd64,com.ora
>> cle.graal.hotspot.sparc,com.oracle.graal.hotspot,com.amd.sumatra
>> 
>> -- Tom
>> 
>> -----Original Message-----
>> From: graal-dev-bounces at openjdk.java.net 
>> [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Doug Simon
>> Sent: Monday, June 03, 2013 9:02 AM
>> To: Venkatachalam, Vasanth
>> Cc: graal-dev at openjdk.java.net
>> Subject: Re: possible bug in mx/projects handling
>> 
>> 
>> On May 31, 2013, at 11:02 PM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> wrote:
>> 
>>> Hi,
>>> 
>>> We have a project com.amd.sumatra which requires java 1.8 compliance to build.
>>> 
>>> We've added lines in mx/project to specify that the project shouldn't be built when building with a 1.7 JDK:
>>> 
>>> distribution at GRAAL@path=graal.jar
>>> distribution at GRAAL@dependencies=com.oracle.graal.hotspot.amd64,com.or
>>> acle.graal.hotspot.sparc,com.oracle.graal.hotspot,com.amd.sumatra
>>> 
>>> # com.amd.sumatra
>>> project at com.amd.sumatra@subDir=graal
>>> project at com.amd.sumatra@sourceDirs=src
>>> project at com.amd.sumatra@dependencies=com.oracle.graal.hotspot,com.ora
>>> cle.graal.hotspot.amd64,com.oracle.graal.hsail,com.oracle.graal.compi
>>> ler.hsail,com.amd.okra 
>>> project at com.amd.sumatra@checkstyle=com.oracle.graal.graph
>>> project at com.amd.sumatra@javaCompliance=1.8
>>> 
>>> When I do an mx build, I see the lines
>>> 
>>> Excluding com.amd.sumatra fro build (Java compliance level 1.8 
>>> required)
>>> 
>>> But then Graal goes ahead and tries to build the package. This appears to be a bug. Can someone look into this?
>> 
>> I tried to reproduce this by creating a local com.amd.sumatra project and used some JDK 1.8 API in it. However, 'mx build' does the expected thing in may case (i.e. does not try to compiled anything in com.amd.sumatra). Could you please send me the output of 'mx clean --no-native; mx -v build' so I can investigate further.
>> 
>> -Doug
>> 
> 
> 
>