Home » Archived » IMP » CVS HEAD (20080221) build woes
| CVS HEAD (20080221) build woes [message #16669] |
Thu, 21 February 2008 16:40  |
Eclipse User |
|
|
|
Originally posted by: karltk.strategoxt.org
Hi gang,
I'm trying to get CVS HEAD built. First some system info:
OS: Xubuntu 7.10, x86, 32bit
JDK: Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing)
Eclipse: 3.2.2 M20070212-1330, Linux 32bit
The only extra set of plugins on top of the classic 3.2.2 Eclipse is the
..66 release, and the 2.0.9 lpg.runtime (which embeds lpg-linux_x86,
IBM LALR Parser Generator Version 1.00 (Nov 27 2007))
(I have also tried with the .70 release, but that didn't change anything.)
The story so far:
1. Checkout of IMP - ok
2. Checkout of LPG - ok
[I used Jurgen's working set].
3. Automatic building of the checked out projects - fail
[I get a hint from Jurgen about templates and bootstrapping.]
4. Generating all .java files from the provided .g files using
lpg on the command line - almost ok.
I end up getting various errors from LPG, mostly shift/reduce conflicts.
Executing
~/source/workspaces/imp3/lpg.generator.linux_x86/lpgexe/lpg- linux_x86
-quiet -list
-include-directory='/home/karltk/source/workspaces/imp3/lpg. runtime.java/templates;/home/karltk/source/workspaces/imp3/o rg.eclipse.imp.lpg.metatooling/templates'
ASTPatternParser.g
in the directory
~/source/workspaces/imp3/org.eclipse.imp.xform/src/org/eclip se/imp/xform/pattern/parser
gives me:
---
ASTPatternLexer.gi:261:31:261:31:5066:5066: Error: The undeclared symbol
"_" is assumed to be a terminal
*** In state 11:
*** Shift/reduce conflict on "IDENT" with rule 24
*** In state 36:
*** Shift/reduce conflict on "IDENT" with rule 43
***Warning: ASTPatternParser.g is not LALR(1).
----
As far as I can tell, I'm using the very latest templates (those I
checked out from CVS -- not those provided by whatever IMP I'm using for
the bootstrapping) both for LPG and for IMP.
In any event, the generated code compiles.
5. Export plugins/features - fail
When trying PDE's Export option, I can successfully export plugins
one by one, but if I try multiple, or if I try to export a feature,
the PDE dependency resolver falls over and claims silly things like
1. ERROR in
/home/karltk/source/workspaces/imp3/org.eclipse.imp.cheatshe ets/src/org/eclipse/imp/cheatsheets/actions/NewBuilderAction .java
import org.eclipse.imp.wizards.NewBuilder;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The import org.eclipse.imp.wizards.NewBuilder cannot be resolved
6. Executing the generated plugins in an Eclipse env - fail
I've generated all the plugins one by one. However, the
org.eclipse.imp feature fails to export because of the PDE builder
problems mentioned above.
Starting an Eclipse env with a full set of CVS HEAD plugins doesn't
work properly. Only some of the plugins register properly, and I
cannot find any exceptions in Eclipse's startup log to guide me.
Okay, as a general rule, one shouldn't put too many issues into one
post, because most will get ignored. I think my biggest problem at
present is to figure out if the grammars should contain shift/reduce
conflicts [and if not, how to fix it].
Cheers,
-- Karl T
|
|
|
| Re: CVS HEAD (20080221) build woes [message #16687 is a reply to message #16669] |
Fri, 22 February 2008 11:35  |
| Eclipse User |
|
|
|
Originally posted by: regenmacher.online.de
LPG is LR-based, so "Shift/reduce conflicts" are quite common. By default
this conflicts results in doing a shift. In most cases (the two examples you
mention included) this is ok.
General Solution:
Increase lookahead-depth (example: %options la=2 resolves your two
"Shift/reduce conflicts" in ASTPatterParser.g, it is LALR(2))
michael
|
|
|
| Re: CVS HEAD (20080221) build woes [message #18186 is a reply to message #16669] |
Fri, 07 March 2008 15:57 |
 Robert M. Fuhrer
Messages: 294
Registered: July 2009 |
Senior Member |
|
|
Karl Trygve Kalleberg wrote:
> Hi gang,
>
First off, thanks for the detailed problem reports; they're
extremely useful!
> I'm trying to get CVS HEAD built. First some system info:
>
> The story so far:
>
> 1. Checkout of IMP - ok
> 2. Checkout of LPG - ok
>
> [I used Jurgen's working set].
The theory is that there will be a "root" Team Project Set checked
into CVS in org.eclipse.imp.update, which lists all of the feature
projects, from which you can obtain per-feature Team Project Sets,
which list all of the plugin projects in that feature. So, starting
from the root, you get everything. The release engineering tools
I've been building will help automate all of this (see a bit more
on this below).
>
> 3. Automatic building of the checked out projects - fail
>
>
> [I get a hint from Jurgen about templates and bootstrapping.]
Yes, this has been a problem since the grammars for IMP-based IDEs
necessarily use IMP-specific templates that are located in
org.eclipse.imp.lpg.metatooling, which is not on LPG's default
include path, since we don't want to introduce a dependency in LPG
on IMP components.
Also, until very recently, our preferences mechanism (which the
LPG IDE uses to specify the include path) didn't provide any way
to specify a plugin-location-dependent value. I.e., one needs to
be able to point the LPG include path to a folder inside the
org.eclipse.imp.lpg.metatooling bundle. Without this, each
developer might have a different absolute path to the templates
folder, and thus the per-project preference setting can't be
shared (checked into source control).
Luckily, we recently enhanced the preferences mechanism to support
"preference substitution", so that a preference value (as typed
by the user into a preference page field) can be something like
${pluginLoc:org.eclipse.imp.lpg.metatooling}/templates
which means the templates folder inside the installed location
of the plugin with the given bundle ID.
With this enhancement, we can now check project-specific LPG
preferences into source control so that projects with LPG
grammars should build correctly "out of the box".
We will do this ASAP (hopefully before the source import to
eclipse.org).
> 4. Generating all .java files from the provided .g files using
> lpg on the command line - almost ok.
>
> I end up getting various errors from LPG, mostly shift/reduce conflicts.
> [...]
>
> In any event, the generated code compiles.
Yes, the shift/reduce conflicts are harmless in this case.
> 5. Export plugins/features - fail
>
> When trying PDE's Export option, I can successfully export plugins
> one by one, but if I try multiple, or if I try to export a feature,
> the PDE dependency resolver falls over and claims silly things like
>
> 1. ERROR in
> /home/karltk/source/workspaces/imp3/org.eclipse.imp.cheatshe ets/src/org/eclipse/imp/cheatsheets/actions/NewBuilderAction .java
>
> import org.eclipse.imp.wizards.NewBuilder;
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> The import org.eclipse.imp.wizards.NewBuilder cannot be resolved
I haven't attempted to use the PDE Export option in ages, for a variety
of reasons. Among other things, it ignores per-project compiler settings.
Also, it doesn't handled linked content at all - the resulting generated
Ant scripts are bogus. It also ignores plugin fragments for any platform
other than the one that Eclipse is running on.
As a result, I've cooked up a series of Ant scripts based on what the
PDE generated long ago, heavily edited and refactored so that, e.g.,
it doesn't embed plugin/feature meta-data (like version #'s, classpaths
and so on) but computes these from the meta-data in the plugin/feature
manifests.
So, there are "exportPlugin" Ant scripts in each plugin project, and
"exportFeature" scripts in each feature project, and a top-level
"exportUpdate" script in the org.eclipse.imp.update project.
Nominally, you should be able to run "exportUpdate" and everything
should build correctly, but I know there are probably still a couple
of issues to iron out.
I've also been working on some release engineering tools to help
manage things like version #'s, file version maps, updating the
update site and feature manifests, and so on. Look at
org.eclipse.imp.versionIncrementer (will soon be renamed to
org.eclipse.imp.releng).
> 6. Executing the generated plugins in an Eclipse env - fail
>
> I've generated all the plugins one by one. However, the
> org.eclipse.imp feature fails to export because of the PDE builder
> problems mentioned above.
>
> Starting an Eclipse env with a full set of CVS HEAD plugins doesn't
> work properly. Only some of the plugins register properly, and I
> cannot find any exceptions in Eclipse's startup log to guide me.
Right, most likely due to PDE-related build problems, rather than
IMP-specific problems.
--
Cheers,
-- Bob
--------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center
IMP Team Lead (http://eclipse-imp.sourceforge.net)
X10: Productivity for High-Performance Parallel Programming (http://x10.sf.net)
|
|
|
| Re: CVS HEAD (20080221) build woes [message #18219 is a reply to message #18186] |
Fri, 07 March 2008 19:19 |
| Eclipse User |
|
|
|
Originally posted by: karltk.strategoxt.org
Hi
> I haven't attempted to use the PDE Export option in ages, for a variety
> of reasons. Among other things, it ignores per-project compiler settings.
> Also, it doesn't handled linked content at all - the resulting generated
> Ant scripts are bogus. It also ignores plugin fragments for any platform
> other than the one that Eclipse is running on.
In order to keep this discussion civil, I will refrain from sharing my
opinions on the PDE builder (and the even worse issue of the Update
Manager).
My 3.3 build patches (linked to in the 3.3-thread) actually restore PDE
export capabilities again -- at least within the limits of PDE.
While this certainly won't be useful in the release process, it's been
useful enough for me during my compilation + bootstrapping exercises. I
therefore hope you will take those patches as well, as they should (to
my understanding) not wreak any havoc with the exist, ant-based, build
scripts.
Cheers,
-- Karl T
|
|
| |
| Re: CVS HEAD (20080221) build woes [message #569783 is a reply to message #16669] |
Fri, 07 March 2008 15:57 |
Robert M. Fuhrer
Messages: 294
Registered: July 2009 |
Senior Member |
|
|
Karl Trygve Kalleberg wrote:
> Hi gang,
>
First off, thanks for the detailed problem reports; they're
extremely useful!
> I'm trying to get CVS HEAD built. First some system info:
>
> The story so far:
>
> 1. Checkout of IMP - ok
> 2. Checkout of LPG - ok
>
> [I used Jurgen's working set].
The theory is that there will be a "root" Team Project Set checked
into CVS in org.eclipse.imp.update, which lists all of the feature
projects, from which you can obtain per-feature Team Project Sets,
which list all of the plugin projects in that feature. So, starting
from the root, you get everything. The release engineering tools
I've been building will help automate all of this (see a bit more
on this below).
>
> 3. Automatic building of the checked out projects - fail
>
>
> [I get a hint from Jurgen about templates and bootstrapping.]
Yes, this has been a problem since the grammars for IMP-based IDEs
necessarily use IMP-specific templates that are located in
org.eclipse.imp.lpg.metatooling, which is not on LPG's default
include path, since we don't want to introduce a dependency in LPG
on IMP components.
Also, until very recently, our preferences mechanism (which the
LPG IDE uses to specify the include path) didn't provide any way
to specify a plugin-location-dependent value. I.e., one needs to
be able to point the LPG include path to a folder inside the
org.eclipse.imp.lpg.metatooling bundle. Without this, each
developer might have a different absolute path to the templates
folder, and thus the per-project preference setting can't be
shared (checked into source control).
Luckily, we recently enhanced the preferences mechanism to support
"preference substitution", so that a preference value (as typed
by the user into a preference page field) can be something like
${pluginLoc:org.eclipse.imp.lpg.metatooling}/templates
which means the templates folder inside the installed location
of the plugin with the given bundle ID.
With this enhancement, we can now check project-specific LPG
preferences into source control so that projects with LPG
grammars should build correctly "out of the box".
We will do this ASAP (hopefully before the source import to
eclipse.org).
> 4. Generating all .java files from the provided .g files using
> lpg on the command line - almost ok.
>
> I end up getting various errors from LPG, mostly shift/reduce conflicts.
> [...]
>
> In any event, the generated code compiles.
Yes, the shift/reduce conflicts are harmless in this case.
> 5. Export plugins/features - fail
>
> When trying PDE's Export option, I can successfully export plugins
> one by one, but if I try multiple, or if I try to export a feature,
> the PDE dependency resolver falls over and claims silly things like
>
> 1. ERROR in
> /home/karltk/source/workspaces/imp3/org.eclipse.imp.cheatshe ets/src/org/eclipse/imp/cheatsheets/actions/NewBuilderAction .java
>
> import org.eclipse.imp.wizards.NewBuilder;
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> The import org.eclipse.imp.wizards.NewBuilder cannot be resolved
I haven't attempted to use the PDE Export option in ages, for a variety
of reasons. Among other things, it ignores per-project compiler settings.
Also, it doesn't handled linked content at all - the resulting generated
Ant scripts are bogus. It also ignores plugin fragments for any platform
other than the one that Eclipse is running on.
As a result, I've cooked up a series of Ant scripts based on what the
PDE generated long ago, heavily edited and refactored so that, e.g.,
it doesn't embed plugin/feature meta-data (like version #'s, classpaths
and so on) but computes these from the meta-data in the plugin/feature
manifests.
So, there are "exportPlugin" Ant scripts in each plugin project, and
"exportFeature" scripts in each feature project, and a top-level
"exportUpdate" script in the org.eclipse.imp.update project.
Nominally, you should be able to run "exportUpdate" and everything
should build correctly, but I know there are probably still a couple
of issues to iron out.
I've also been working on some release engineering tools to help
manage things like version #'s, file version maps, updating the
update site and feature manifests, and so on. Look at
org.eclipse.imp.versionIncrementer (will soon be renamed to
org.eclipse.imp.releng).
> 6. Executing the generated plugins in an Eclipse env - fail
>
> I've generated all the plugins one by one. However, the
> org.eclipse.imp feature fails to export because of the PDE builder
> problems mentioned above.
>
> Starting an Eclipse env with a full set of CVS HEAD plugins doesn't
> work properly. Only some of the plugins register properly, and I
> cannot find any exceptions in Eclipse's startup log to guide me.
Right, most likely due to PDE-related build problems, rather than
IMP-specific problems.
--
Cheers,
-- Bob
--------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center
IMP Team Lead (http://eclipse-imp.sourceforge.net)
X10: Productivity for High-Performance Parallel Programming (http://x10.sf.net)
|
|
|
| Re: CVS HEAD (20080221) build woes [message #569861 is a reply to message #18186] |
Fri, 07 March 2008 19:19 |
Karl Trygve Kalleberg
Messages: 7
Registered: July 2009 |
Junior Member |
|
|
Hi
> I haven't attempted to use the PDE Export option in ages, for a variety
> of reasons. Among other things, it ignores per-project compiler settings.
> Also, it doesn't handled linked content at all - the resulting generated
> Ant scripts are bogus. It also ignores plugin fragments for any platform
> other than the one that Eclipse is running on.
In order to keep this discussion civil, I will refrain from sharing my
opinions on the PDE builder (and the even worse issue of the Update
Manager).
My 3.3 build patches (linked to in the 3.3-thread) actually restore PDE
export capabilities again -- at least within the limits of PDE.
While this certainly won't be useful in the release process, it's been
useful enough for me during my compilation + bootstrapping exercises. I
therefore hope you will take those patches as well, as they should (to
my understanding) not wreak any havoc with the exist, ant-based, build
scripts.
Cheers,
-- Karl T
|
|
|
Goto Forum:
Current Time: Thu Apr 25 08:35:56 GMT 2024
Powered by FUDForum. Page generated in 0.03901 seconds |
] 
Search
Help
Register
Login
Home
