Assuming a default build.gradle without using a real file

Hello,

I have the following issue for my custom language plugin:

1) I do not want to bother supporting makefiles directly, though if it is really a relatively straightforward process I might consider it.

2) I wrote a gradle wrapper script for Makefiles that seems to work well enough; it should work for any (ok, most) Makefiles without modification.
However, IntelliJ, at least on Windows, does not like to follow soft symbolic links, and I really hate the idea of copying this build.gradle file all over the place for
projects that have many makefiles that are being used in a hierarchical fashion. Soft links would be bad enough.

A better seeming solution would be for the project to simply assume that this build.gradle is being used, unless there is already a build.gradle in the project's directory.
Now, aside from the issue of figuring out how to tell the gradle plugin to check if we are using my language plugin, there is the issue of making gradle itself aware of this
virtual file (or tempory file, or file stored in a non-project location). In this way, this wrapper build.gradle file will not be put into source repositories for people that aren't
using IntelliJ, etc.

Is this a reasonable thing to do?

Any pointers on where to start?

3 comments
Comment actions Permalink

Why do you need to tell IntelliJ's Gradle plugin about your build.gradle? I find it very unlikely that the plugin would be able to import anything useful from your build.gradle file, since I assume your custom language does not use the standard Java project model.

I think that you to write a JPS plugin to support compilation of your files in any case. Inside of the plugin, you can delegate to make or to Gradle or to any other tool you like.

0
Comment actions Permalink

Thanks Dmitry,

You are correct that probably nothing useful could be ascertained from the build.gradle.

So for now I've just suggested people can use it if they want to, until I get proper support.

I found a document, which I see you worked on some - I'll give it a read through next time I get a chance and start working on it.

A related point -- the language I'm working with in this case is tightly related to C, as it is a C code generating language (actually, it can generate other language code as well, but C is the primary target). So to some extent, I've wondered how much I can "piggy back" on top of a C language plugin. CppTools seems to be on the way out, but was still very helpful for me to refer to a number of times. I'm not sure if it makes sense for me to work with integrating on top of CLion yet, as it seems to be non-free and only available for 30 day periods of evalutation. Not a big issue, as there are still many things I can work on, just a bit curious as to the future in case it could impact my planning.

0
Comment actions Permalink

CppTools hasn't been actively developed for quite a while, and I would recommend against building on top of it. CLion is indeed going to be a commercial product; right now there are no plans for a free edition.

0

Please sign in to leave a comment.