[gyp-developer] Will ever support other programming languages?

[Igor Gatis]

My projects are written in c++, java, python, with inter dependencies. Any chance gyp will be my ultimate build tool?

[Bradley Nelson]

Hi Igor,

C++ and python are reasonably well supported. Java, well not so much.

We probably should put more effort into it.

You can currently handle java as an action where you just feed everything into javac,

but nothing out of the box.

Rules would likely be a bad fit, given the outputs don't directly relate to inputs.

What's really missing I guess is the moral equivalent of scanners/generators in scons.

Dunno, depends on how much Java I suppose.

We'd like to do better of course. Can you tell us more about your use case?

-BradN

[Igor Gatis]

I've got a couple of tools written in Python and Java which use C++ libraries using SWIG.

Currently, I'm handling java projects with ant build scripts I wrote myself. Ant build files are quite nice and reasonably simple.

Perhaps the best approach to support java better is to generate build.xml and use ant to compile it.

For other languages, it seems rule would be enough. But I noticed there is a bug in the rules mechanism which prevents one to create generic rules. In my case, I wonted to create a rule which compile .proto files. My generic rule doesn't work because it gyp rule mechanism requires sources up front. I reported that here with the solution but no one took care of it. Perhaps you could take a look.

[Igor Gatis]

It would be really nice if, besides generating build.xml, generated make/xcode/msvc projects automatically called ant.

[Bradley Nelson]

Sorry about the patch languishing. I'll try to take a look this week or early next.

-BradN

[Igor Gatis]

I found some time to try adding support for java. In the patch attached, I added support for make generator only (which still needs polishing). In high level, support works as follows:

+ There is this new target "jar" type it takes java sources and jar files (see below) as input and spits a single jar file (named after target name).

+ Sources are .java files which user specifies using 'sources' section. Pretty much in the same way one would do with C++ targets.

+ The new "classpath" section holds the list of jar files which will be passed as classpath parameter to javac compiler. The jar file can be another "jar" target or actual jar files (using "=" prefix).

+ The new "injars" sections holds the list of jar files which will be merged into final output jar. Just like "classpath", items can be either "jar" targets or actual jar files (using "=" prefix).

Here is an example:

{

  'targets': [

    {

      'target_name': 'mylib',

      'type': 'jar',

      'sources': [

        'src/gyp/MyLib.java',

      ],

    },

    {

      'target_name': 'mylib-to-embed',

      'type': 'jar',

      'sources': [

        'src/gyp/MyLibToEmbed.java',

      ],

    },

    {

      'target_name': 'hello',

      'type': 'jar',

      'classpath': [

        'mylib',

        '=lib/external.jar',

      ],

      'injars': [

        'mylib-to-embed',

        '=lib/external-to-embed.jar',

      ],

      'sources': [

        'src/gyp/HelloWorld.java',

      ],

    },

  ],

}

[Igor Gatis]

Oops, I a stale diff. Here is one which actually works.

[Ryan Sleevi]

Hi Igor,

I'll admit, I haven't looked at your patch at all, so please don't take this as a statement one way or the other.

GYP tries to follow the same Contributor workflow as projects like Skia, V8, or Chromium use. This involves filling out a Contributor License Agreement and using http://codereview.chromium.org for code reviews.

You can find out about this workflow at  http://dev.chromium.org/developers/contributing-code , including the references to the necessary tools (namely, depot_tools) and the links to the Individual or Corporate CLAs.

Once you've filled out a CLA and uploaded your patch, it will be easier to review.

That said, one thing to consider is that it's often hard to upstream large code chunks, especially where there hasn't been much high level discussion about what the syntax should look like. I know you're not alone in wanting to be able to use GYP with Java projects, and having reviewed a fair bit of the GYP work that the Chrome for Android team has done to integrate their build tools, I can definitely see how, as currently implemented, it's a bit unwieldy.

As such, it might be better to first discuss what the necessary features and changes should be, before any review of the actual patch happens. Since I personally haven't had a need for Java integration with GYP, I've copied some other Chromium developers who might have opinions on the proposed syntax and what they might want. I'll admit, I'm not a big fan of the '=' prefix syntax, and I would think any dictionary/array that needs to support both targets and files should instead be split into two keys (one for GYP targets, one for actual files).

It may be that others feel GYP isn't the right tool for this at all, given the complexity emergent in many Java build systems, but I'm certainly willing to entertain the discussion.

[John Grabowski]

Hi Igor.  

For the medium term we're planning on using ant for Chromium Android work.  Part of the reason is simplicity; Android has a lot of "build magic" provided by jars that implement the build actions.  Although certainly possible to reverse engineer, isn't clear how easy or stable it would be for us to extract the relevant actions.

Can you tell me your intended use case for java within gyp?

Ijrg

[Igor Gatis]

My intent is to be able build C++ and Java targets using a single command. In http://code.google.com/p/protobuf-j2me/ (or http://code.google.com/p/protoserv/), for example, I have this Java target which depends on protoc (protocol buffers compiler) which is written in C++. If I change something in the compiler, I'd like build system to rebuild protoc before building Java target. The dependency in indirect in this case (C++ code wont be "linked" to Java code). But I totally see the scenario where one wants to build a JNI library to be packed together with the Java target.

[John Grabowski]

OK, that seems reasonable.  

Your needs are a bit orthogonal to what Chromium Android is doing right now, so there isn't a lot of overlap.  It would probably be better if Core Gyp people (e.g. not I) review your patch to maintain gyp consistency.

jrg