search

Frege / frege

Frege is a Haskell for the JVM. It brings purely functional programing to the Java platform.
https://github.com/Frege/frege/wiki/_pages
Other
3.64k stars 145 forks source link

Question: Gradle Build #97

Closed ysb33r closed 9 years ago

ysb33r commented 9 years ago

Would people be interested in me migrating the build from GNU Make over to Gradle?

seancorfield commented 9 years ago

Could you explain how that would be an improvement?

ysb33r commented 9 years ago

As an improvement to the Frege compiler itself - none.

As an improvement to the building environment, here's a couple:

I see this as a multi-phase approach.

  1. Wrap around Make - there is already a Gradle plugin to do this. Sounds silly, but it allows for the safe removal of targets from the Makefile and rewriting into Gradle, with Gradle handling the task dependency management. It will also allow adding the facility to publish to Bintray with little effort.
  2. Move all Java building into Gradle. Granted this will be a bit of fun given the way the compiler needs to get built, but it sure will be a lot easier than trying to do it in Maven.
  3. Remove any last tasks from Makefile and see what can be done about yacc. (Any pure Java implementations? javacc springs to mind, but that is a top-down parser)

My own personal motivation above an beyond all of that is having had to write too many customised Makefiles in past years. As this is a hard-core JVM project it should benefit from a build tool that simplifies life building JVM projects. Ant is too old and without native dependency management will yield little benefit. Maven, although still going strong, is not the easiest tool to work with when it comes to customising the build outisde of the classic Maven-way. Gradle OTOH, offers a lot as a new generation tool. It has a easy to read DSL, it makes light work of dependency management and task dependency management and it has the powerful feature of being able to bootstrap itelf, from a simple script & jar that is committed to soure control.

mikowiec commented 9 years ago

Migration to the Gradle building tool would be good for dependency decreasing, specially for Windows users. Migration tool from Cabal to Gradle would be great too.

mperry commented 9 years ago

I would like to see migration to Gradle. I suspect it would greatly simplify the makefile and make publishing artifacts easy.

Ingo60 commented 9 years ago

As said before, I symphatize, but can't help here due to lack of knowledge.

Dierk commented 9 years ago

I usually prefer Gradle for all kinds of automatic builds but the Frege make has its own benefits. Maybe we can use Gradle additionally for tasks like publishing of artifacts. (We may want to consider publishing to bintray) Pull requests are welcome :-)

Cheers Dierk

sent from:mobile

Am 06.02.2015 um 04:30 schrieb Mark Perry notifications@github.com:

I would like to see migration to Gradle. I suspect it would greatly simplify the makefile and make publishing artifacts easy.

— Reply to this email directly or view it on GitHub.

ysb33r commented 9 years ago

I have to concur here on the use of make. I have started to look at the conversion and there are things in the Makefile that will not be trivial to convert to Gradle.

We can use the gnumake plugin to call make from Gradle and then use Gradle to perform the publishing and dependency management.

mperry commented 9 years ago

So others don't have to repeat your work @ysb33r can you comment on the Gradle difficulties?

ysb33r commented 9 years ago

@mperry, here are some of the main things I have noticed.

  1. What to do about yacc. There is no direct pure-JVM equivalent. There is javacc and the is CUP, but neither are drop-in-replacements.
  2. Building both JDK6 & JDK7 JARs. AFAIK this is not possible within the normal java compile tasks of Gradle - it might require the creation of Gradle subprojects
  3. The way that $(COMPF)/grammar/Frege.class is being built. Tweaking this without subprojects will probably create a Gradle file more complex than the existing Makefile.
Ingo60 commented 9 years ago

Folks,

I symphatize very much with efforts to devise a build system usable with Frege projects. (I am, however, neutral concerning the question if it should be leiningen or gradle or whatever, though. (Please forgive me!))

However, please keep in mind that, as Schalk (@ysb33r) already pointed out, the compiler build itself is a bit different. I strongly recommend starting with something more easy.

Concerning yacc, there is another point to consider. Not only must a would-be drop in be able to make fast, LALR shift/reduce code. It must also make Frege code . I am not willing to have the core part of the compiler written in Java. If you can read yacc, you'll notice that the semantic actions are written in frege. To rewrite them in Java would be an absurd undertaking, and a constant pain in the ... errm, I mean, it would be hard to maintain (i.e. in the case where the calling conventions change, etc.)

But I guess running a command is not the point (or is it?). The more severe and atypical thing is the compiler-bootstraps-itself in 3 stages. This is something one cannot expect a build tool to handle out-of-the-box.

That being said, it must be noted that the Makefile has already gotten leaner, thanks to the -make option of the compiler itself, that fully handles the compilation of all needed frege files in the correct order. I estimate another 50% of the Makefile could go, and is only left in for (let's be straight) laziness and sloppiness of the author.

We could also make a light version of the bootstrap, i.e. one which leaves out the first 2 stages. But then, to compensate for the extensive self-test the 3-stage bootstrap gives us, we would need a thorough regression test suite. (This would be in itself and indepedently of the other concerns a worthy goal anyways.)

Just my 2 cents.

seancorfield commented 9 years ago

On December 31st I asked "how that would be an improvement?" and I think this discussion shows that for the compiler itself it would not be an improvement.

In terms of building stuff with Frege @talios already maintains https://github.com/talios/frege-bundle on Maven Central and the compiler itself is easy to run from other code (I built a Leiningen plugin for Clojure using the old compiler API - I need to update it for the simpler compiler API now available). @talios already has a Maven plugin to compile Frege code. If someone wants to create a Gradle plugin, that seems fruitful too.

Trying to replace the compiler's make-based system - which @Ingo60 relies on - seems a bit pointless to me.

ysb33r commented 9 years ago

I was not aware of frege-bundle. This will make life a lot easier building a Gradle plugin that is much more gradlesque than the current one.

I would just like to see that the frege-bundle is aways up to date, with the latest release of frege. Therefore I would think that it is better for Frege to publish itself rather than rely on @talios. I would like to see publishing to Bintray as well (which can auto-push to MC anyway). If Frege wants to take on the publishing then we can revisit this thread and wrap around Gnumake with Gradle.

Even though i created this discussion, I am siding with @seancorfield at this point - I see little point in changing the build system at this point. I am more interested in using frege in projects without effort. (Maybe the README should just refer to @talios).

talios commented 9 years ago

On 8 Feb 2015, at 12:31, Sean Corfield wrote:

Trying to replace the compiler's make-based system - which @Ingo60 relies on - seems a bit pointless to me.

Yep - the two build issues are separate IMHO - one for building/developing Frege itself, and the other for developing projects/applications using Frege ( of which having maven, gradle, lein, buck etc. support would be good.

Improving the build tool FOR Frege may be a nice, longer term ideal and may even mean more contributions, but that should be a separate step to end-user build tool support.

Mark

Mark Derricutt http://www.theoryinpractice.net http://www.chaliceofblood.net http://plus.google.com/+MarkDerricutt http://twitter.com/talios http://facebook.com/mderricutt

Ingo60 commented 9 years ago

I think we have a consensus on the following points:

The development of the Gradle plugin (which aims for such a solution) will be carried out in its own sub-repository. Thanks to @mperry and @Dierk, who want to join their efforts on this. For this reason, I think this issue can be closed, and further discussions concerning Gradle/Groovy integration should take place in the issue tracker of the relevant repository.

Dierk commented 9 years ago

+1

Am 15.02.2015 um 01:14 schrieb Ingo Wechsung notifications@github.com:

I think we have a consensus on the following points:

• Don't touch the compiler build environment for now. • General solutions for integrating Frege with the JVM ecosystem are very welcome. The development of the Gradle plugin (which aims for such a solution) will be carried out in its own sub-repository. Thanks to @mperry and @Dierk, who want to join their efforts on this. For this reason, I think this issue can be closed, and further discussions concerning Gradle/Groovy integration should take place in the issue tracker of the relevant repository.

— Reply to this email directly or view it on GitHub.