I was thinking about Ivan parsing Version from the build.fan, how I generate the build.fan in afGenesis, and how Maven and Gradle read their properties...

...and thinking, wouldn't it be nice if build::BuildScript read, and populated itself, from a build.fog file!?

If this was a Fantom standard then IDE's, installers and other programs could programmatically read, and more importantly write, project data via the build.fog.

Currently, it is very difficult for a program to edit build.fan as it is a source file. But if the data was (optionally) moved out to a separate file, say build.fog, then programs could easily read and edit it.

Then libraries / pods could contain little scripts to add themselves to a project with cmds like:

$ fan afIoc -install

Programs like afGenesis could then easily add dependencies to existing projects, and so forth.

It seems like a nice little addition to me. Does anyone else have any thoughts on this?

Its actually a tricky problem - there is clearly a need for IDEs to get access to metadata like build version from a declarative file. But it sure is handy to script some stuff in larger systems. We actually for a period of time (think 2007-2009) moved stuff like build version out into a props file (actually think it was sort of like a special fog file). But it was messy and I was never happy with that. So I still consider it an open problem.

I'm not sure what problems were encountered, but how about this:

As it's only pod data we want to alter, it's only fields in BuildPod we need to serialise. So what if all these fields were duplicated in a BuildPodMeta class that is saved as build.fog next to build.fan. The BuildPod ctor could read this instance of BuildPodMeta (if it exists) and copy the field values into itself.

This essentially defaults the build.fan values to the data in build.fog. When the build.fan ctor then executes, it then has an opportunity to override the field values.

This would mean that, going forward, all new build.fan scripts can use build.fog. But given build.fog is optional you can still script the values should you wish. It also means it's backwards compatible with all existing build.fan scripts.

Some overly simplified pseudo code:

abstract class BuildPod : BuildScript {

  new make() {
    loadMetaFromFog()
  }

  Void loadMetaFromFog() {
    if (!`build.fog`.toFile.exists)
      return

    meta := `build.fog`.toFile.readObj
    meta.typeof.fields.each |field| {
      value := field.get(meta)
      this.typeof.field(field.name).set(this, value)
    }
  }

  ...
}


@Serializable
class BuildPodMeta {
  Str? podName
  Str? summary
  Version? version
  ...
}

not sure what problems were encountered

Basically the thing that I really disliked is having to create two files for each pod. The meta-data file then became the primary file, and the script file was just boiler plate. So for a little while the plan was to get rid of the script and have a "build" tool you ran against the meta-data. But I didn't really like that either since it was a loss of flexibility. So in the end, I just fell back to the original script only design.

The meta-data file then became the primary file

Ah, yes, I see. It would yeah!

script file was just boiler plate.

Yeah, it'd be tiny also - essentially just an empty class file with BuildPod doing all the work.

I didn't really like that either since it was a loss of flexibility

That'd be because (I imagine) the script file was ditched altogether. Couldn't we do something like have the "build tool":

1. Check for a build.fan - if it exists, run it (which does the optional .fog loading)
2. If not, check for a build.fog - if it exists, run a default build.fan passing in build.fog.

That way you could still run the build.fan script directly (should you wish). The build tool just runs your script (if it exists) or runs a default one with your build.fog...?

Well there was a ton of work on that basic idea. Maybe see 936 for history. I still think that might be right direction, but obviously it is a massive change to how building works today, so its not something to tackle lightly.