<https://medium.com/@josephivie/idea-kotlin-as-a-b...

# random

[josephivie]

https://medium.com/@josephivie/idea-kotlin-as-a-build-system-306842b4bede

[leolima]

Something like http://beust.com/kobalt/home/index.html ?

[josephivie]

Not quite - I've looked at Kobalt, and I was hoping to help with multiplatform on Kobalt, but unfortunately I haven't had time yet.
I'm thinking something way more minimalistic. Kobalt is more or less a fixed version of Gradle - it still has a full-blown task system, a plugin-oriented structure, and has magic execution - i.e. there's no clear entry point where the script is running.
Don't get me wrong, I like Kobalt because it leverages many of Kotlin's features better, but can we do with just some libraries and vanilla Kotlin scripting? It might be a bit more verbose, but I think it's quite possible the clearness when reading might be worth it.

[josephivie]

Code snippet was fixed in the article.

[karelpeeters]

You want every script to be something like

fun main(args: Array<String>) {
    ActualBuildSystem.run(args) {
        sourcePath("src/kotlin")
        //other stuff
}

Where ActualBuildSystem is "just" a library then?

[karelpeeters]

Because that's what going to happen, no one wants to write code to actuall read files or call the Kotlin compiler.

[josephivie]

@karelpeeters Almost, actually - they'll be calling into libraries to do most of their work. That's the point though - we're just using libraries at this point, which are exchangable, combinable, and multilayered. I imagine the average project using various libraries in its build script might look like:

val dependencies = listOf<Dependency>()
val project = JavaProject(
    sources = File("./src"),
    dependencies = dependencies,
    output = File("./build")
)
val testingModule = JUnitTesting(
    sources = File("./src"),
    dependencies = dependencies,
    testingSources = File("./tests"),
)
fun build() = project.build()
fun test(filter: String? = null) = testingModule.runTestsMatching(filter ?: "*")

But now imagine I need to do something more complex - I could call into a lower-level library where I can mess with the exact calls to the compiler.

[cedric]

@joseph_ivie I can see the appeal of that but there’s only so much you can “ignore the compiler”. This will work for simple tasks such as just compiling or creating jar files (which might take you some distance), but as soon as you want to do a bit more, a library needs to exist.

[josephivie]

@cedric I'm not entirely sure I understand what you're saying - I wouldn't use straight scripting either if there weren't libraries available in the build script to make calling the compiler/running tests/etc easy. I'd like those to truly just be libraries though - standard Maven dependencies declared at the top of the script, able to be used by any other project as well, build system or not.

[josephivie]

Just added a bunch of content to the article to make my intentions clearer.

[cedric]

@josephivie About:

Figuring out how to run a specific function in a Kotlin script from the command line

Maybe https://github.com/cbeust/kash would help

[Nikky]

and one of the new features in 1.3.40 is cashing a evaluated script into a runnable jar.. seems like it would be useful here

[cedric]

@Nikky I've been using the 1.3.40 ea for a while, because of some new script related features. And 1 3.50 contains additional new features that Kash will leverage too.

[cedric]

Ilya has been sending PR's to Kash to help with this.

[josephivie]

@cedric That's awesome!

[napperley]

What are some of the new scripting features which are useful?

[cedric]

They are mostly fixing bugs 🙂

[cedric]

Among which, support for args in custom script engines (which Kash is) and fix the debuggability of these scripts (1.3.50)

[sksk]

that is what i hope for kotlin, get rid of gradle

[tmg]

I think it's great idea!

[josephivie]

https://github.com/UnknownJoe796/kbuild

[cedric]

@josephivie Interesting idea but I wonder if you don’t quickly run into limitations, e.g. plug-ins. Can you use kbuild to, say, generate fat jars, or upload to bintray, etc…?

[josephivie]

A fat jar is a task, and tasks are just functions, and functions can come from loading plain Maven libraries into your script. So while I haven't built functionality like that, anyone could create it just be creating a new library that makes fat jars! I've defined a couple interface which you could use in KBuild to make integration easier, but you don't need them at all.

[cedric]

Is that your project, Joseph?

[cedric]

FYI Your link Plain Kotlin and Kotlin with Maven is broken

[cedric]

I don’t see how to write tasks in that README, is it somewhere else?

[josephivie]

I'll draw up an example in a bit here

[josephivie]

That's correct, this is my project. I'll take a look at the link.
That's because there are no 'tasks'. They're just functions. Kotlin already has 'tasks' in that sense, and using object-oriented, we can extend them as we please already to do things before and after.

[cedric]

I understand that, I just don’t see how to create my own from a build, e.g. creating my “plug-in”

[josephivie]

Here's a link to the tests: https://github.com/UnknownJoe796/kbuild/blob/master/src/test/kotlin/com/ivieleague/kbuild/KotlinJVMModuleTest.kt

[josephivie]

Here you go @cedric! https://github.com/UnknownJoe796/kbuild#extending

[josephivie]

Just added that section.

[josephivie]

Also just added this statement, which I think makes my intentions more clear:
"It's just a set of tools for building Kotlin more conveniently from Kotlin itself, and as such, is really more a concept or idea more than any kind of library"