[e-lang] Remove the binary distributions?

[Thomas Leonard]

There's quite a lot of complexity (and slowness) in the E build for
producing platform-specific releases (e.g. E-win32-x86-0.9.3a.zip). Is
anybody using these?

The build process seems to be:

- src/bin/* contains various SWT binaries (presumably out-of-date by
now; last update was Feb 2008)
- just the binaries for the building platform get copied to dist/bin/$osdir
- dist gets copied to export/dist
- export/dist gets copied to export/puredist
- export/puredist/bin/$osdir is deleted

How would people feel about having a single E release (just puredist),
without any jars? This means that people writing SWT applications would
be responsible for distributing swt.jar with their application somehow
(e.g. using a Maven pom.xml, a 0install feed, or bundling a copy).

However, you already have to do that anyway if:

- You're producing non-Windows releases
- You're producing 64-bit Windows releases
- You're producing 32-bit Windows releases using an up-to-date SWT
- You want to use other libraries

We could make the rune "run" command depend on SWT in the 0install feed
so that the SWT example scripts continue to work without extra effort
(for people using 0install). That would avoid making every E program
depend on SWT (e.g. headless servers). People not using 0install or a
distribution package manager would need to install SWT for their
platform manually.
--
Dr Thomas Leonard
IT Innovation Centre
Gamma House, Enterprise Road,
Southampton SO16 7NS, UK


tel: [phone]

mailto:***@it-innovation.soton.ac.uk
http://www.it-innovation.soton.ac.uk/

[Kevin Reid]

Post by Thomas Leonard
There's quite a lot of complexity (and slowness) in the E build for
producing platform-specific releases (e.g. E-win32-x86-0.9.3a.zip). Is
anybody using these?

I can't speak for anyone else, but I have in the past used the Mac SWT releases while trying to get SWT to work. This little use case would probably be better served by a little note about "where to get SWT", but see below.

Post by Thomas Leonard
How would people feel about having a single E release (just puredist),
without any jars? This means that people writing SWT applications would
be responsible for distributing swt.jar with their application somehow
(e.g. using a Maven pom.xml, a 0install feed, or bundling a copy).

In theory, SWT is to be the standard GUI library for EoJ. *.e-swt scripts (such as those included in the EoJ distribution) should just work out of the box.

In practice, considering that SWT is native code where the rest of E isn't, and variously platform/version-dependent, I think it would be OK to say "get SWT <prominent link to specific instructions here> if you want to use these GUI programs".

Possibly relevant: I am in favor of simplifying EoJ's build process.

Higher-level point: I think we should reconsider to what degree we want to be writing E programs that are tied to Java at all.

Post by Thomas Leonard
We could make the rune "run" command depend on SWT in the 0install feed
so that the SWT example scripts continue to work without extra effort
(for people using 0install). That would avoid making every E program
depend on SWT (e.g. headless servers). People not using 0install or a
distribution package manager would need to install SWT for their
platform manually.

I need some context.

Who uses 0install other than you?

What do you mean by 'the rune "run" command'? Rune does not have anything I would consider subcommands.

My understanding of 0install is that package are identified with their entry points. If rune depends on SWT, how do you get headless E without SWT?

[Thomas Leonard]

Post by Kevin Reid

Post by Thomas Leonard
There's quite a lot of complexity (and slowness) in the E build for
producing platform-specific releases (e.g. E-win32-x86-0.9.3a.zip). Is
anybody using these?

I can't speak for anyone else, but I have in the past used the Mac SWT releases while trying to get SWT to work. This little use case would probably be better served by a little note about "where to get SWT", but see below.

Post by Thomas Leonard
How would people feel about having a single E release (just puredist),
without any jars? This means that people writing SWT applications would
be responsible for distributing swt.jar with their application somehow
(e.g. using a Maven pom.xml, a 0install feed, or bundling a copy).

In theory, SWT is to be the standard GUI library for EoJ. *.e-swt scripts (such as those included in the EoJ distribution) should just work out of the box.
In practice, considering that SWT is native code where the rest of E isn't, and variously platform/version-dependent, I think it would be OK to say "get SWT <prominent link to specific instructions here> if you want to use these GUI programs".
Possibly relevant: I am in favor of simplifying EoJ's build process.
Higher-level point: I think we should reconsider to what degree we want to be writing E programs that are tied to Java at all.

Post by Thomas Leonard
We could make the rune "run" command depend on SWT in the 0install feed
so that the SWT example scripts continue to work without extra effort
(for people using 0install). That would avoid making every E program
depend on SWT (e.g. headless servers). People not using 0install or a
distribution package manager would need to install SWT for their
platform manually.

I need some context.
Who uses 0install other than you?

In general, people use 0install when the program they're trying to run uses it.

If you want figures, it's hard to say. Each distribution has its own
package in its repository with its own stats. e.g. for Debian:

http://qa.debian.org/popcon.php?package=zeroinstall-injector

Though what these figures mean I'm not entirely sure. I think it's
estimating that 0.67% of Debian users currently have it installed.

sf.net says we have had 137,362 downloads in total, but that includes
all the tools too, not just the main 0install program.

Post by Kevin Reid
What do you mean by 'the rune "run" command'? Rune does not have anything I would consider subcommands.

When you launch a program, 0install runs the "run" command by default.
e.g. these run e-core's "run" command:

$ 0launch http://repo.roscidus.com/e/e-core
?

or

$ 0alias rune http://repo.roscidus.com/e/e-core
$ rune
?

In e-core's XML, it looks like this:

<command name="run">
<runner interface="http://repo.roscidus.com/java/openjdk-6-jre">
<arg>-De.home=$EHOME</arg><arg>org.erights.e.elang.interp.Rune</arg>
</runner>
</command>

Currently, this gets you a non-SWT version of E. We could provide an
extra "run-swt" entry-point, e.g.

<command name="run-swt">
<runner interface="http://repo.roscidus.com/java/openjdk-6-jre">
<arg>-De.home=$EHOME</arg><arg>org.erights.e.elang.interp.Rune</arg>
</runner>
<requires interface="http://repo.roscidus.com/java/swt">
<environment insert="swt.jar" name="CLASSPATH"/>
</requires>
</command>

Then you could do:

$ 0launch --command=run-swt http://repo.roscidus.com/e/e-core

Or we could do it the other way around, having "run" and
"run-headless" commands.

Post by Kevin Reid
My understanding of 0install is that package are identified with their entry points. If rune depends on SWT, how do you get headless E without SWT?

There are a couple of options:

1. E programs can specify e-core as their <runner>. By having multiple
commands as above and using a command-specific dependency, programs
can set their <runner> to "run" or "run-swt". So an E program might
declare its runner as e-core, like this:

<command name='run' path='myprog.e'>
<runner interface="http://repo.roscidus.com/e/e-core" command='run'/>
</command>

By changing the command name in the <runner>, the program could select
the SWT or headless commands in e-core.

2. An E program can specify Java as its <runner> and e-core as a
library. In that case, none of e-core's runners is used. Then SWT can
be added as any other dependency. For example:

<command name='run' path='myprog.e-swt'>
<runner interface='http://repo.roscidus.com/java/openjdk-6-jre'>
<arg>-De.home=$EHOME</arg><arg>org.erights.e.elang.interp.Rune</arg>
</runner>
</command>
<requires interface="http://repo.roscidus.com/e/e-core">
<environment name="CLASSPATH" insert="e.jar"/>
<environment name="EHOME" insert="" mode='replace'/>
</requires>
<requires interface='http://repo.roscidus.com/java/swt'>
<environment name='CLASSPATH' insert='swt.jar'/>
</requires>

Although longer, it means that SWT isn't a special case. Also, this
way allows you to pass extra Java options (e.g. heap size), and you
have to give the dependencies explicitly if you want to set version
contraints (e.g. SWT >= 3.6). This is the method we currently use.

It probably depends whether you care about the Java integration (we
do). The first form hides the fact that it's using Java.

[Bill Frantz]

Post by Kevin Reid
In theory, SWT is to be the standard GUI library for EoJ.
*.e-swt scripts (such as those included in the EoJ
distribution) should just work out of the box.

FWIW - I haven't used E to write GUI programs. I've used it for
reducing data logger data, so it's read files, process, write output.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz | I like the farmers' market | Periwinkle
[phone] | because I can get fruits and | 16345
Englewood Ave
www.pwpconsult.com | vegetables without stickers. | Los Gatos,
CA 95032