Where is an exact definition of what goes in sinan.config? Or just help me port this old .cfg file?

[enew...@gmail.com]

Sorry, can't find this info anywhere.  What is the specification for a sinan.config file?

I need to port this from a prior Sinan version that worked fine:

project : {

  name : ecd

  vsn  : "0"

},

ignore_dirs : ["."],

tasks : {

  build : {

    compile_args : "-W1 +debug_info +nowarn_unused_function +warn_obsolete_guard +warnings_as_errors"

  }

},

releases : {

  web_ui : {

    vsn  : "0"

    apps : ["web_ui", "ecd_ops", "ecd_ops_agent"]

  }

  ecd_match : {

    vsn  : "0"

    apps : ["core_engine", "ecd_ops_agent", "ecd_ops_engine", "ecd_sec",

            "ecd_report", "ecd_access_control_engine"]

  }

  ecdconsole : {

    vsn  : "0"

    apps : ["ecd_console", "ecd_ops", "ecd_ops_agent"]

  }

  behave : {

    vsn  : "0"

    apps : ["behave"]

  }

}

[Eric Merrit]

You can take a look here for more detail -> 

https://github.com/erlware/sinan/wiki/SinanConfig

Just to help out this would be converted to 

{project_name, ecd}.

{project_vsn, "0"}.

{compile_args,  args}.

Compile args now take the exact same thing that the compile module does (since the config is now in erlang term format).

(no need for ignore_dirs anymore I believe)

For the releases bit you can take a look at this  for converting the format ->

https://github.com/erlware/sinan/wiki/ConfiguringMultipleReleases

--
You received this message because you are subscribed to the Google Groups "erlware-questions" group.
To view this discussion on the web visit https://groups.google.com/d/msg/erlware-questions/-/lBQKAzDlhVYJ.
To post to this group, send email to erlware-...@googlegroups.com.
To unsubscribe from this group, send email to erlware-questi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/erlware-questions?hl=en.

[enew...@gmail.com]

Is there no way to list only the apps one wants in a release?  It seems a bit crazy to specify a release by listing all the apps that one DOESN'T want in the release.

[Eric Merrit]

Think about the common case. The common case is one release with every app in the project. That is specified for you and considered the default. Other releases are articulated as variations from that standard. So release 'foo' is the same as default except it doesn't have app bar (or it has bar at version xxx) etc.  Thats why its articulated that way.  

To view this discussion on the web visit https://groups.google.com/d/msg/erlware-questions/-/aDgaHZkdR_0J.

[enew...@gmail.com]

Common?  I have never encountered any other build system that requires that I list libraries that I don't want in order to produce an executable.

What happens because of this is that developers create new applications that accidentally get included in releases that they didn't know about.  Developers need to repeat themselves once for every excluded app per release.  Developers are lost when someone asks them how many apps are in a particular release.

It seems that Sinan is optimized to get someone going quickly but then hits this wall when multiple releases need to share a few common library applications.

Can Sinan build library applications without generating a release?  Then I could mandate one Sinan project per release and I would need a Makefile to run Sinan multiple times.

[Eric Merrit]

On Sep 19, 2012, at 1:16 PM, enew...@gmail.com wrote:

Common?

Absolutely, in both the current users of Sinan and the greater Erlang world as a whole. 

 I have never encountered any other build system that requires that I list libraries that I don't want in order to produce an executable.

ok. 

What happens because of this is that developers create new applications that accidentally get included in releases that they didn't know about.  Developers need to repeat themselves once for every excluded app per release.  Developers are lost when someone asks them how many apps are in a particular release.

Again this use case is *uncommon (given the constraints above)*, so we do everything we can to make the common use case a no brainer and then give the ability to do something different when it needs to be done. 

It seems that Sinan is optimized to get someone going quickly but then hits this wall when multiple releases need to share a few common library applications.

Sinan is optimized for those projects where most things in the project are related to a single release. 

Can Sinan build library applications without generating a release?  Then I could mandate one Sinan project per release and I would need a Makefile to run Sinan multiple times.

Absolutely, just don't do a sinan compile rather then a sinan release. 

To view this discussion on the web visit https://groups.google.com/d/msg/erlware-questions/-/qFH9vMubVuUJ.

[enew...@gmail.com]

Bottom line is that I am now faced with having to maintain manually the opposite of the transitive closure of all dependent apps per each release.

Common should be easy.  Complex should be possible.  What I have here is very tedious and error prone.  There are so many disadvantages to doing it this way I need to find some other tool.  Symlinks?  But then I have the same transitive closure nightmare but now in the file system through symlinks.

[Eric Merrit]

On Sep 19, 2012, at 2:33 PM, enew...@gmail.com wrote:

Bottom line is that I am now faced with having to maintain manually the opposite of the transitive closure of all dependent apps per each release.

How do you mean? Dependencies all work as the have. The top apps in the project are your default goals you can add or remove from those and then transitive dependencies are resolved normally. 

Common should be easy.  Complex should be possible.

Granted.

 What I have here is very tedious and error prone.  

I agree its not optimal. This is just a feature that has not seen a lot of love since there are few if any users. 

There are so many disadvantages to doing it this way I need to find some other tool.  

Rebar has pretty much won the erlang build system space for better or worse. I am currently working on the recool project that takes Sinan's release building ability and generalizes it for use outside of sinan (and specifically for rebar projects). Its in a working state but is still very young (and it does offer the features you are looking for). 

I won't recommend it simply because I literally just got it building releases last night, but rebar + recool is where I am moving my projects over time.

Eric

To view this discussion on the web visit https://groups.google.com/d/msg/erlware-questions/-/b9LH7AUeecMJ.