Hi Dave,
Well in an ideal world it would be great to have LOTS of
software approved by Eclipse Legal and thus ready for
redistribution.
But in the world today, the resources of the Eclipse Legal
team are limited and thus any work they would do for ANTR tools is at the
expense of other libraries to be approved. Of course you could go and apply for
ANTLR tools, mention in a comment that it's not strictly required (i.e.
communicate the priority you see for it), and then have the Eclipse Legal team
determine if and when they want to review. Perhaps they'd do some initial review
to estimate rough size of the work and if it's even realistic to ever get it
approved. That may be helpful, but with Galileo wrapping up now you'd get even
such initial feedback not before August I guess.
Given the long time it needs to get something approved, you
also need to keep in mind that the library (ANTLR tools) evolves at the same
time, so at the time Eclipse Legal is ready to review 3.1 you may already want
3.1.5.
Because of these things, and because I guess you want to
get something out of the door, I believe that you'll have to live with
downloading ANTLR tools separately for some time at least. Thus my initial
suggestion.
If you still believe that you'd want the tools eventually ,
you can file a CQ since it's always good to communicate your intent and wishes
to those who know what to do with them. Be sure to communicate clearly your
priority.
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
Martin,
Thanks, it does
help.
One last try at
convincing you that distributing the whole antlr jar might be a good thing
…
- the current XDCtools product
(from TI) does ship the ANTLR tool (we build and test with the same pieces
delivered to the customer)
- the only other tools required to
build XDCtools are a java compiler and a native host C compiler (and a
previous release of XDCtools). Everyone who expects to rebuild
something for eclipse has both Java and C already in installed on the
development host as are SCM tools.
- it's one more tool and a
sequence of steps that can go wrong; just because there are other error
prone steps doesn't mean we can add one more without feeling
guilty
- I might be wrong, but I thought
Ant was shipped with eclipse.
That said, if your
intuition is that requiring contributors (and committers) to manage the ANTLR
tool as a separate "component" of their build environment is better than
trying to re-distribute ANTLR within XDCtools (and eclipse), then we'll go
with just the runtime. After all, we _can_ work around the issue and build
procedures are not easy.
This raises a related
question. We (like many other teams) place all of the tools used to
produce a product under change control so, if necessary, we can reproduce the
product many years after it has been released. Is there a list of all
tools used to build eclipse published with each release of eclipse?
Thanks
again,
dave
From:
Oberhuber, Martin [mailto:Martin.Oberhuber@xxxxxxxxxxxxx] Sent: Monday, May 04, 2009 2:17
PM To: Russo,
David Cc: DSDP PMC list Subject: RE: antlr
CQ
Hi
Dave,
after a
little thought, I think you should apply for ANTLR runtime
only.
I find
it quite natural that non-EPL tools are required for building some software:
just think about compilers for the DLL's / sharedlibs (MS devstudio, gcc,
make), CM tools (subversion), build tools (ant). It's not unexpected IMO that
the build instructions for RTSC include instructions where to get and how to
install the full ANTLR from some 3rd party source. Since you're not going to
ship the ANTLR tools, nobody will care whether they are under EPL or
not.
At the
same time, you should probably think about committing the ANTRL-compiled
grammars into CVS/SVN -- basically the counterpart of committing precompiled
DLL's / sharedlibs into CVS like the Platform team
does.
Does
that help?
Cheers,
--
Martin Oberhuber, Senior Member of
Technical Staff, Wind
River
Target Management
Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
From:
Russo, David [mailto:d-russo@xxxxxx] Sent: Montag, 04. Mai 2009
23:03 To: Oberhuber,
Martin Subject: RE: antlr
CQ
I
believe it only covers the ANTLR runtime not the tool itself: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=3270.
From:
Oberhuber, Martin [mailto:Martin.Oberhuber@xxxxxxxxxxxxx] Sent: Monday, May 04, 2009 1:59
PM To: Russo,
David Subject: RE: antlr
CQ
Did
you check ipzilla whether any version of antlr has been approved
already?
I seem
to remember that older versions were deemed not to be EPL compatible whereas
a newer one (antlr 3.1 ??) was approved.
Cheers,
--
Martin Oberhuber, Senior Member
of Technical Staff, Wind
River
Target
Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
From:
Russo, David [mailto:d-russo@xxxxxx] Sent: Montag, 04. Mai 2009
22:55 To: Oberhuber,
Martin Cc: Russo,
David Subject: antlr
CQ
Martin,
I have a "judgment call"
question I'd like your opinion on.
Background
As you probably know, the RTSC
IDL is implemented using and ANTLR grammar. In addition, in order to
ensure RTSC build tooling is regularly tested with "real use", we use RTSC
to re-build the RTSC tools. For the RTSC team there is little
difference between
· what
is required to build RTSC
and
· what
is required to use RTSC
(except for the target C compilers of course).
During the IP review of the
XDCtools, we have a pre-requisite dependency on ANTLR. Other
projects only require the ANTLR runtime; i.e., a subset of the ANTLR
distribution sufficient to use an ANTLR generated grammar. But, in
order to re-build the RTSC project's tools from source, more than the
runtime is required; the ANTLR tool itself must be used to "compile" the
supplied grammar. Since we currently use RTSC tools to build RTSC's
tools we currently distribute more than just the runtime - we distribute
an unmodified antlr.jar that contains both the runtime and the ANTLR
tool. However, like other projects, to _use_ RTSC tools only the
runtime is required.
Question
Should I request an IP review
of the _entire_ ANTLR
package (tool and runtime) so that RTSC can re-build RTCS without
additional installation steps ("get the full antlr jar with the right
version and copy … then modify …."),
Considerations
Re-building RTSC is obviously
low on most peoples list of priorities so if it's complicated it may not
be a big deal. Moreover, I don't want to "rock the boat" by
insisting on something we can work around. On the other hand,
re-distributing the unmodified antlr.jar from antlr.org ensures that the
right version of the ANTLR tool is always available and no additional
installation steps are required to rebuild the IDL (in case someone want's
to quickly try a change/addition to the
Grammar).
From an ease of use point of
view, I'd much prefer to distribute the complete ANTLR. From an
eclipse community member point of view, I don't want to unnecessarily
burden others with work just for my convenience. Any comments or
perspectives would be appreciated.
Thanks
dave
|