[etlas] Add field build-uberjar:

[rahulmutt]

The workaround is to make an executable with a stub main function.

[jneira]

hi, what do you mean with "add field"?

[rahulmutt]

It means to be able to specify build-uberjar: in the Cabal file.

executable
   ...
   build-uberjar: True

OR

library
   ...
   build-uberjar: True

(While False will be the default value.)

So this change involves:

1. Adding the field to the Cabal fields parser and modifying the existing data types like LocalBuildInfo or any of the related types to store that info.
2. Updating Distribution.Simple.ETA.buildLib/Exe to check for that field and send the appropriate flags to the eta compiler.

[jneira]

Ok, the change would suppose the deprecation/elimination of -enable-uberjar-mode config option?

Anyway i'll try to take a look.

[rahulmutt]

Deprecation and eventual elimination, yes.

Sounds great!

[jneira]

Maybe related with #285: with the new way maybe clean the dist folder dir would not be required?

OTOH i am thinking in a differente approach to implement this, taking in account #267 and #265:
If we added a new value deployment-mode=uberjar (as suggested in #267), we would not need another field in the config file.
Moreover, with this option and maven-provided (as in #290) we will have the spark mode covered, no?

[rahulmutt]

So in light of the recent changes (in the going-stackless branch), the story for how we're going to handle concurrency has become very clear. Which means compiling the etlas-cabal library with Eta itself is just a matter of porting directory and process properly and handling some of the platform-specific details.

What this means is that we'll be able to support build-type: Custom and we can make packages for each deployment mode (supporting uberjar deployment within the etlas-cabal package itself since it's common) and it's just a matter of adding a dependency and setting up the Setup.hs file accordingly. So we can defer all the issues you mentioned until after that branch gets merged to master.

And I agree with your point that making a uberjar is simply another mode of deployment and should be unified with that concept.

[rahulmutt]

It turns out this is not necessary.

You can create a cabal.config with a single line:

uberjar-mode: True

To get the same effect.