Hi,

I'd like to specify pod version in build script outside of the script itself. I.e. normally it looks like

using build

class Build : build::BuildPod {
  new make() {    
    version = Version.fromStr("1.0.1")
    ...

I'd like to have 1.0.1 in a separate file in order for third-party tools to be able to easily get and set it.

Now, I've done something like this:

using build

class Build : build::BuildPod {
  new make() {    
    version = Version.fromStr((scriptDir + `version`).readAllLines.first)
    ...

version file contains the version.

This is not very good. I know, that the default version is taken from $FAN_HOME/etc/build/config.props. But can I have a local config.props file for just one pod? I haven't found a way to do it.

Specifying FAN_BUILD_buildVersion env var is also not an option, since this way one who has just the build script wouldn't know, where to get the version.

Well its a script, so you can really code up whatever solution you like. I think what you have seems fine to me if that is where you want to store the file. What do you not like about that solution?

I typically use etc/build/config.props myself, but have different working directories for the various projects - so each project maintains its own build versions.

Soemtimes I also use env variable for more complex build scripts where I tweak patch versions, etc

Hi, I remember suggesting a similar idea in the topic Move BuildScript state into an external file but it didn't get much traction.

The idea is fairly simple and (I believe) backwards compatible; an (optional) Build.fog lives alongside Build.fan. Build.fog is a serialised version of Build.fan. When Build.fan runs, it loads Build.fog (if it exists) and copies the values over.

Tools could easily parse and edit the Build.fog and humans could override the values and behaviour in Build.fan.

Of course, moar details would need to be discussed...

Hi brian,

Thank you for the answer. I gave you the simplest case, and in this case, everything is fine. What I don't like is the need to code this solution manually. Please, consider the case of using BuildGroup:

using build

class Build : BuildGroup
{

  new make()
  {
    childrenScripts =
    [
      `child1/build.fan`,
      `child2/build.fan`,
      `child3/build.fan`,
      `child4/build.fan`,
      `child5/build.fan`,
      `child6/build.fan`,
      `child7/build.fan`,
      `child8/build.fan`,
    ]
  }

}

In this case, if I want all children to have the same version, it is not that trivial. I actually have such a project as well, and the only reasonable thing I've come up with is to copy/paste that solution 8 times for each childN/build.fan, which is obviously not ideal.

Having version in etc/build/config.props is OK for local environments, but if you want to use CI server, for instance, what should you do?

Actually, the fact that it is a script and you can code whatever you like, can be a disadvantage. As you can see in this case, no external tool can understand version (and other variables) for sure without actually running build.fan. This is a significant shortcoming, when you start thinking about automation of your processes.

This is why I thought, that it may be advantageous to have some default non-scripting way to specify some core parameters like version (may be others as well, like dependencies).

@SlimerDude, yes, I was thinking about something like this. I'm not sure, which format of Build.fog you're thinking about. If it is something wide-spread, like .ini/properties file, it should be OK.

.fog = fantom object graph, it's the standard Fantom serialisation format.

Look at %FAN_HOME%\etc\fluxText\text-editor.fog for an example. It's much more expressive than a .props file and they're super easy to convert into a statically typed Fantom class:

obj := `wotever.fog`.toFile.readObj

As for versioning child scripts, you could pass the version as a cmd line parameter when you call script. The child scripts themselves could then parse Env.cur.args to see what was passed in. But I think what you have now (with the version file) works better.

copy/paste that solution 8 times for each childN/build.fan, which is obviously not ideal.

If you want to formalize a solution in your own project, then you can create your own subclass of BuildPod and use that - that is the beauty of the build engine, its an open ended framework that lets you do anything you can code up in Fantom

Although personally, I really like just like injecting it via an environment variable.

A long time ago we had build meta pulled out into a more declarative file, it had some nice advantages. But in the end we switched back to build scripts for flexibility and consistency. If the community comes up with some ways to augment what we have (say to do per pod versions), then we can certainly look at adding it into the core. Or it might just be a build library people add into their environment that enhances the core build APIs.