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.
To view this discussion on the web visit https://groups.google.com/d/msg/erlware-questions/-/aDgaHZkdR_0J.
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.
To view this discussion on the web visit https://groups.google.com/d/msg/erlware-questions/-/qFH9vMubVuUJ.
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.
To view this discussion on the web visit https://groups.google.com/d/msg/erlware-questions/-/b9LH7AUeecMJ.