On 3/20/07, Karl Fogel <kfogel@red-bean.com> wrote:
>
> "Mark Phippard" <markphip@gmail.com> writes:
> > The problem is that for these files to "work" they pretty much have to
> live in
> > the root of what the user will checkout. That is the only place Eclipse
> is
> > going to look for them and since they are needed to configure the
> project
> > properly you need them right from the beginning.
>
> Hmmm. Let's get concrete: if you could put them right where you
> wanted them, without regard to anyone else using the tree, what are
> the exact files and where would they live? (If they're all under a
> .settings dir, for example, I doubt anyone would mind...)
I have attached a sample patch that shows the files that would be added.
This is relative to trunk.
Generally speaking, these files should not require much change once they are
set. The Java-specific files might only require a few more tweaks to get
the code formatting settings to our likely. Right now I have the settings
pretty good though. I can ask Eclipse to reformat a JavaHL file according
to these rules and the diff is pretty minimal. So that tells me as we write
new code in Eclipse, it would do a good job helping the user write the code
to our standards.
On the C side, if we really wanted to use Eclipse I think there would be
changes to some of these files as they store configuration about the
tool-chain and I am not setup for any of that. The current C tools have
decent code formatting rules, but they are stored in your global
preferences. So we cannot provide them with the project. We could store an
exported Eclipse preference file in contrib or some place like that for
people to import the settings.
I am not sure if the C files are setup in a way that they can hold different
configurations for different platforms. If they are not, then I imagine
that would mean users on different platforms would have to adjust the
files. I think if that turned out to be the case, we could again store
recommended copies in contrib and the user could fiddle with them.
The files in this patch are for Eclipse 3.3 and CDT 4.0, both of which will
be GA in June. It is pretty common for Eclipse users to be using the
milestone builds at this point and CDT has a number of code formatting
improvements in this release that made it worth using.
To test the patch, apply it to your working copy. It could be trunk or a
branch. You should then have an Eclipse 3.3 install with CDT 4.0 and
Subclipse 1.2.0 also installed. Then just do File -> Import to start the
Import wizard. Under the General category select "Existing Project into
Workspace". Then select your project root. This imports the project into
Eclipse (which just means it points Eclipse at it). It should be all ready
to go, including being connected with Subclipse. Of course, once these
files were in the repository, a new user could just do this all via Checkout
in Subclipse and it would all setup automatically.
If you have Eclipse 3.2, it will also work but the JUnit configuration will
not be present because this patch is using a new Eclipse 3.3 feature for
that. So the Java classes that use JUnit will have compile errors.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 21 15:49:47 2007