Compilation OE 10.2 and Developer Studio

Each version of PDS is only able to run the executables it installs with.  PDS uses the prowin32 or _progres to perform the actual compiles and these only compile to a single target version.

There is no way to setup PDS to compile to a different target version.

Look into setting up a build system outside your development environment if you ned to target specific versions.  I suggest using http://code.google.com/p/pct.

Hi Matthew,

I know that a prowin32 compile can be targetted just for a single version. But on my station, I've got 2 different install ( 10.2 and 11.2 ).

If it's possible to run, in PDS, a project using OE version 11 or 10, I have some trouble to believe that PDS can't build a project in version 10.

I saw when yuou create a new project, when you select a "Project Facets", it's possible to select OpenEdge version 10. But I have an error when I select it.

Here is a screenshot in attachment.

When I was testing with OE11, I just had 10.2 installed on my desktop and 11.2 installed on my laptop.  I synchronized the source and compiled each version as needed.

To manage 2 versions on one workstation, which practical in theory, is so unnecessarily complicated or even impossible that I wouldn't even attempt it.

With any Windows setup, installing 2 versions of the same application is not recommended.

The best solution is as Matthew Baker suggests, Set up pct and ANT, if you plan to do this long-term.

Or if you're just testing, set up 2 stations and be done with it.

Using multiple parallel branches in the SCM tool of your choice is another option.

Having various versions of Progress installed on a developer or end user PC is no problem.

How do you proceed when you have, for example, 2 projects which turn on different OE version? When you want to work on it? I'm talking about IDE (with OE10, it's Architect and OE11, it's PDS)

you can configure the 2 separate installs to compile into separate directories, usually shared folders in a production enviroment.

fyi - if you have 2 different database versions running production, you will need separate licenses for each.

In my example I was only testing v11.

Note: I'm waiting for v11.3 to arrive, then we will get v11 appserver and connect to our 10.2 databases, until our ERP provider is able to upgrade to v11 later this fall. So I'll be compiling 10.2 for our normal custom, and will compile 11.3 for appserver. (at this point I don't know even if I need to compile v11 for appserver, but I'm sure I'll find out.)

I use the IDE of the Progress Version I work with.

But we also use PCT with Ant/Jenkins for integration testings after every source commit.

Mike are you talking about  2 Progress versions on the same OS "instance"?  I wasn't brave enough to try this...

I could see doing this on 2 vm's and launching via Virtualbox - call one oe10.2 vm and one oe11 vm.

Never had a problem with multiple Progress versions (including betas) on the same Windows installation since 8.3 or so.

The only thing to consider is to NEVER set a system wide DLC variable. There's just no need for that.

Never had a problem with multiple Progress versions (including betas) on

the same Windows installation since 8.3 or so.

I've had up to 5 (I think) concurrent OE installs on a single Windows machine for years now without problem.

The one area of conflict is the Admin Server; by default it runs on port 5162 (regardless of OE version). There are a couple of ways around this.

My preferred way is to not use Windows services: stop the Admin server and set to Manual start. Then, when I need to use that version's Admin Server, I start it in proenv via 'proadsv -start' and -stop when I'm done. (Now that I think about it, it might be useful to be able to start/stop the admin server from PDSOE but that's not possible today).

You can also change the ports the admin server runs in in the registry somewhere, but (clearly) I've not done that (otherwise I'd remember where :).

The only thing to consider is to NEVER set a system wide DLC variable.

There's just no need for that.

>

100% agree with this. You can set local (to a script) DLC's and/or use the proenv shell for the version you want, which does that for you quite nicely.

-- peter

Now that I think about it, it might be useful to be able to start/stop the admin server from PDSOE but that's not possible today

Any batch script can be integrated into PDSOE using the external tools.

However, I'm satisfied with setting the Admin Services to manual start and then starting the appropriate Admin Server from the services control panel (quickest way to get the IMHO is to launch services.msc on any version of Windows).

That's right, I've 2 differents OE version installed on my station and it works fine.

But I wanted and I was thinking that PDS could provide multiple configurations to build a project (the one using prowin32 from DLC10/ and the 2nd one using prowin32 from DLC11/ , for example) .

Switching between Architect and PDS is not a comfortable solution, but that's only my opinion.

And what about Project Facets that I have shown you previously? What is it exactly?

Switching between Architect and PDS is not a comfortable solution, but that's only my opinion.

Agreed.

That's right, I've 2 differents OE version installed on my station and it

works fine.

But I wanted and I was thinking that PDS could provide multiple

configurations to build a project (the one using prowin32 from DLC10/ and

the 2nd one using prowin32 from DLC11/ , for example) .

Switching between Architect and PDS is not a comfortable solution, but

that's only my opinion.

The Launch Configs can use any installed version of OE. You could write your own .P that performed the compilation based on a directory structure. You can pass various Eclipse-related parameters to the ABL runtime via session:parameter; there's a 'Variables' button next to the 'Session startup parameter' field on the Startup tab in the Launch Configurations option.

HTH,

-- peter

Apologies, scratch this answer. Not all installed version appear in the launch config (I recalled this being true at one point and didn't actually check).

Given that, Mike's suggestion of an Ant-based approach is (probably) the most robust.

-- peter

Hi.

Some of our Roundtable TSMS customers intercept our compile event hooks and fire off a secondary (or even more) compilation with each object compilation.

Jeff