Re: [platform-cvs-dev] Setting up shared multiplatform developmentenviro

[Pawel Pogorzelski <Pawel.Pogorzelski@xxxxxxxxxx>]

Mikael,
got it, you want to use branches to
version platform dependent files. What you propose is a tool to map resources
to branches against which to synchronize. This leads to a more general
question whether CVS client should encourage users to mix tags within the
project. Honestly I’m not in favor of that solution as it complicates
work model with CVS.

However if you feel it’s something
worth considering please open an enhancement request for Platform CVS to
gather opinions of other people interested. I'm not an expert in this matter
since I don't use CVS in a way you do.

Regards
--------------------
Pawel Pogorzelski
Software Engineer
IBM SWG Krakow Lab, Poland

IBM Polska Sp. z o.o. oddzial w Krakowie
ul. Armii Krajowej 18
30-150 Krakow
tel. +48-12-628-9682

NIP: 526-030-07-24
Sad Rejonowy dla m.st.Warszawy, XIII Wydzial Gospodarczy KRS
KRS 0000012941, Kapital zakladowy: 33.000.000 PLN

"Mikael Hakman" <mhakman@xxxxxxxx>
Sent by: platform-cvs-dev-bounces@xxxxxxxxxxx

2009-03-06 11:56

Please respond to
"Eclipse CVS Integration developers list."        <platform-cvs-dev@xxxxxxxxxxx>

To	"Eclipse CVS Integration developers list." <platform-cvs-dev@xxxxxxxxxxx>
cc
Subject	Re: [platform-cvs-dev] Setting up shared multiplatform        developmentenvironment

Pawel,
 
You’re quite right – cvsignore isn’t suitable
in my case. I need different versions of some files downloaded into a project
depending on platform, not to ignore the files. One would think that this
is a quite common problem in all multiplatform projects including, as you
write, Eclipse itself.
 
I understand your description of how things
are setup in the development of Eclipse itself. You have some projects
that are relevant to some platforms only and then you manually select these
projects when working with (on) those platforms. I do this too – I use
a lot of JNI and every JNI C project has an accompanying Java project which
exposes that functionality using Java class(es), more or less in 1:1 relation
to original native calls. These projects are platform specific and are
downloaded manually into Eclipse as needed. Above that I have platform
independent abstraction layers in Java consisting of interface definitions,
factory methods, and a set of implementations of these interfaces against
above low level platform dependent Java classes. I do this in order to
minimize C/C++ programming and work in Java as much as possible.
 
However, my original question was about something
else. Here are 2 examples. A JNI C project needs different tool chain and
different build settings depending on actual platform even if its C-code
itself is fully portable. This means that you need different versions of
.cproject file. All other source files are platform independent and therefore
you don’t want separate projects for each and every platform in this case.
 Another example is build/run time classpath in a Java project which
varies between platforms, which requires different .classpath files. All
other files are platform independent. Again, you don’t want separate projects
for each platform only because classpath changes. Then there are e.g. the
.def files (needed and referred to only on win32), C++ files with inline
assembly code, etc., etc.
 
I think CVS itself has already all the functionality
required. You can accomplish all this by manually and carefully setting
up things in CVS and then equally manually and carefully downloading/updating/committing
them to/from Eclipse. What we don’t have in Eclipse is a way to automate
that and make it fool-proof and developer friendly. I would say we need
a way to _configure_ a project with appropriate versions (branches) of
various files and then refer to such a configuration by a name. Most of
the files will be from HEAD (or whatever your “current head” is), some
of the files will be from platform dependent branches.
 
Perhaps this is something that Eclipse/CVS
project could take a closer look into.
 
Thanks/Mikael
On Friday, March 06, 2009 10:14 AM, Pawel Pogorzelski
wrote:

Mikael, 
it seems to be impossible to do with Eclipse/CVS. I think CVS has only
one facility to select which files to include in synchronization operations,
it’s cvsignore. It’s not suitable for your case though.

I can tell you the way it's done in Eclipse itself since it contains platform
dependent code. First of all the separation is made on the level of projects,
not individual files. So, you have projects like org.eclipse.core.net,
org.eclipse.core.net.win32.x86 and org.eclipse.core.net.linux.x86. This
way you download common code and the one that corresponds to your platform
but the decision is user made. 
Mikael Hakman wrote:

Hello,

I'm setting up shared multiplatform development environment. Eclipse/CVS
will be used on multiple platforms and clients to develop applications
for 
multiple platforms. I have difficult to figure out how to setup shared
projects. Perhaps you could help. Here is the situation.

A project consists of a number of platform independent and a few platform
dependent files. Platform dependent files consist of .project, .classpath,
.cproject etc. files and some other .java, .cpp etc. files. All files should
be versioned. When checked out (or updated) on platform A, only platform
independent and platform A files should appear (be updated) in the 
workspace. The reverse should be done when checking in (committing). On
platform L only platform independent and platform L files should appear.
On 
platform W only platform independent and platform W files should be worked
on, etc. The set of platform independent files is the same across all 
platforms (new files and directories may be added for all platforms). Sets
of platform dependent files may differ between platforms.

While setting up a project may be complex and take some time, checking
out, 
updating, and committing during normal development should be foolproof
- 
developers should focus on development, not on CVS issues.

Any help would be deeply appreciated.
 _______________________________________________
platform-cvs-dev mailing list
platform-cvs-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-cvs-dev