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
