eclipse_tour

Your IP: 38.107.179.210
View number: 621
Should be useable now.

1. Reference materials

2. Tool chain(s)

3. Development environment

4. Why our example is different.

There turns out to be a number of gotchas in using the "Hello World" example hard coded into the Autotools plug-in:

• The Eclipse-CDT setup assumes your doing native development out of the box.
• The "Hello World" example assumes the same and evidently does a global "Restore Defaults" in its template.
  Meaning that all of the carefully crafted cross-compile build configurations get wiped out.
• Although the Eclipse-CDT supports CVS (and GIT, SVN) out of the box, we are using the Mercurial (hg) plug-in.
  Since HG is a distributed source control system, the wording of the stock panels can be hard to relate to HG operations.
• The operation of both our Published and Un-Published Mercurial repositories is such that a person typically starts with a pair (local and remote) of empty repositories.
  The procedure described here has been changed so that the starting point is two, empty repositories placed in-sync with each other rather than making a clone of the empty remote repository.

4.1. Mercurial is a distributed source control system

Each instance of a directory tree under hg version control is complete unto itself. There is no concept of a "Central Repository" in this distributed source control system other than that established by user policy.

What makes each instance different is the contents of the .hg/hgrc file in the instance. This file is instance local and never transferred.

As a matter of use-case policy, the published (visiable in the web interface) repositories here are "owned" by the member that created them. Any member that has requested repository services has write authorization to both their private (in the sense that these are not shown in the web interface) and their published repositories.

At the moment of this page's writing, the server side automation that allows each owner to administer the server-side repository instance is not complete. It requires manual intervention by myself, our remote-agent script does not (yet) know how to fill in the server-side .hg/hgrc file.
Someday, RSN. . . . .

4.2. Mercurial as a web site master repository

Once a member has write access to the service, they create their remote repository with the "hg init ..." command. The same as they do for their local file system repositories, only the URI is different.

Then either the service's administrator (me) or the remote-agent script will fill in the server-side .hg/hgrc file.

The server-side .hg/hgrc file of the example dummy repository looks like this:

[web]
description = Eclipse-CDT Dummy
contact = minimod at morethan.org
hidden = false
allowpull = true

[ui]
username = mikez ~lt~minimod at morethan.org>

Which can be seen (since: hidden = false) in the list of published site repositories.
This example, empty, repository may be cloned (since: allowpull = true) as a read-only copy by anyone.
A member who just created an empty repository would be able to clone a read/write copy.
The procedure described in this HowTo does a "push" of an empty local repository to an empty remote repository to establish the initial in-sync condition.

4.3. Site repository service structure

Repositories accessed via HTTP are "public, read-only". Write access via HTTP is not supported.
All write access is controlled by ssh/rsa public-key authentication for both public and private work spaces.

From the viewpoint of site access, there are three repository service trees:

• hg.minimodding.com/repos/[topic]/
  Any repository in this tree may or may not be visible in the web interface; under owner's control.
• hg.minimodding.com/users/[username]/
  Features same as above, only organized as a per-member tree.
• hg.minimodding.com/[username]/
  The "private" (never http published) per-member repository tree. This tree has at least one repository, the member's administration repository controlling the features of the repositories then own.

Every repository has an "owner" - the member who created it.
Every repository supports "group collaboration" where the group is one (the owner) or more people; as determined by that repository owner.
While the member who created a repository is the "owner" and "primary administrator", that owner may specify additional "sub-administrators".

4.4. Site repository URI structure

For public (read-only) clones of the repositories displayed in the web interface, the URI is simply the URL of the repository's name (left most column).

For all other access, ssh with 2,048 bit RSA public key authentication is used.
The URI structures are:

• ssh://authority/repos/[topic]/[repo name]
• ssh://authority/users/[user name]/[repo name]
• ssh://authority/[user name]/[repo name]

The last of the three shown is used by the member to access both their administrative repository and their private repositories.

Examples of the third form can be seen in this HowTo, as:
ssh://hguser/mmghg/[repo name]

The authority field (hguser) is an entry in the user's home .ssh/config file that gives a short-cut name to all of the authority details required by ssh.

The user name field (mmghg) is the members repository service, user name. Not required to be the same as the web-site user name but commonly is the same. (In these examples, it is not a web-site member name.)

The tree structure of the repository collections is created by the user when they create the repository by name. The field shown above as: "repo name" may contain path components, even non-existent path components.

5. Compatibility Issues

As of this writing, there are known in-compatibilities between the tests generated by autoconf and certain Debian/Squeeze compilers.

I have not researched this to find if it is a problem with the generated tests (an autoconf problem) or a change in the series-4 compilers.

Known Status

Distribution: Debian/Squeeze, x86_64
gcc-3.4 works
gcc-4.1 works
gcc-4.2 none shipped
gcc-4.3 fails to properly execute the ./configure tests
gcc-4.4 fails to properly execute the ./configure tests

Code Sourcery, Cross compilers for MIPS
mips-sde-elf-gcc (4.3) works
mips-linux-gnu-gcc (4.3) works

Users must set their environment to a working gcc compiler!
Either by manually setting the link in /usr/bin or using your distribution's update-alternative utility.

You can test your own setup by installing "autoproject" and then doing a quick example.
Specify each available compiler as: CC=whatever ./configure
If your sample project fails to complete the configuration test, bit bucket that compiler!

6. Installed software

Since Eclipse/CDT is primarily just a GUI wrapper on top of your existing development tools, knowing what tools I had installed while developing this Wiki page may become significant.

The first thing to check if your results are different than this Wiki page is the versions of the external tools you are using.

6.1. Installed Auto Tools

mszick@deb2core:~$ dpkg --list 'auto*' | grep 'ii'
ii  autoconf                             2.67-2                               automatic configure script builder
ii  automake                             1:1.11.1-1                           A tool for generating GNU Standards-compliant Makefiles
ii  autopoint                            0.18.1.1-3                           The autopoint program from GNU gettext
ii  autoproject                          0.20-5                               create a skeleton source package for a new program
ii  autotools-dev                        20100122.1                           Update infrastructure for config.{guess,sub} files

6.2. Installed Mercurial (hg)

mszick@deb2core:~$ /usr/bin/hg --version
Mercurial Distributed SCM (version 1.6.4)

6.3. Installed native compilers

mszick@deb2core:~$ dpkg --list 'gcc*' | grep 'ii'
ii  gcc                                  4:4.4.5-1                            The GNU C compiler
ii  gcc-3.4                              3.4.6-9                              The GNU C compiler
ii  gcc-3.4-base                         3.4.6-9                              The GNU Compiler Collection (base package)
ii  gcc-4.1                              4.1.2-29                             The GNU C compiler
ii  gcc-4.1-base                         4.1.2-29                             The GNU Compiler Collection (base package)
ii  gcc-4.2-base                         4.2.4-6                              The GNU Compiler Collection (base package)
ii  gcc-4.3                              4.3.5-4                              The GNU C compiler
ii  gcc-4.3-base                         4.3.5-4                              The GNU Compiler Collection (base package)
ii  gcc-4.4                              4.4.5-8                              The GNU C compiler
ii  gcc-4.4-base                         4.4.5-8                              The GNU Compiler Collection (base package)
ii  gcc-4.4-doc                          4.4.4.nf1-1                          documentation for the GNU compilers (gcc, gobjc, g++)
ii  gcc-4.4-multilib                     4.4.5-8                              The GNU C compiler (multilib files)
ii  gcc-doc                              5:3                                  documentation for the GNU compilers (gcc, gobjc, g++)
ii  gcc-doc-base                         4.4.4.nf1-1                          several GNU manual pages
ii  gcc-multilib                         4:4.4.5-1                            The GNU C compiler (multilib files)

6.4. Selected native compiler

mszick@deb2core:~$ ls -l /usr/bin/gcc*
lrwxrwxrwx 1 root root      7 Dec 18 11:37 /usr/bin/gcc -> gcc-3.4
-rwxr-xr-x 1 root root  90712 Oct 25  2008 /usr/bin/gcc-3.4
-rwxr-xr-x 1 root root 222472 Apr 11  2010 /usr/bin/gcc-4.1
-rwxr-xr-x 1 root root 239528 Sep 20 20:01 /usr/bin/gcc-4.3
-rwxr-xr-x 1 root root 255536 Nov 14 20:04 /usr/bin/gcc-4.4
-rwxr-xr-x 1 root root  16013 Oct 25  2008 /usr/bin/gccbug-3.4
-rwxr-xr-x 1 root root  16288 Apr 11  2010 /usr/bin/gccbug-4.1

6.5. Installed cross-compilers

mszick@deb2core:~$ ls -l /opt/mips-4.3
total 24
drwxr-xr-x 2 root root 4096 Jun  8  2009 bin
drwxr-xr-x 3 root root 4096 Jun  8  2009 lib
drwxr-xr-x 3 root root 4096 Jun  8  2009 libexec
drwxr-xr-x 6 root root 4096 Apr 12  2009 mips-linux-gnu
drwxr-xr-x 5 root root 4096 Jun  8  2009 mips-sde-elf
drwxr-xr-x 3 root root 4096 Jun  8  2009 share

7. Preliminaries

There are a few things you need to decide and/or look-up about your own installation before following this Wiki example.
Things which will differ on your installation from what I show here, which is based on my installation.

Since this process is mostly a "fill-in-the-blanks" exercise, its handy to have the answers before you start.

7.1. Path to your installed hg

mszick@deb2core:~$ whereis hg
hg: /usr/bin/hg /usr/share/man/man1/hg.1.gz

7.2. The short-cut name you set in your own .ssh/config file, mine:

host hguser
     user hgadm
     hostname hg.minimodding.com
     port 22
     IdentitiesOnly yes
     IdentityFile ~/.ssh/hg.minimod/mmghg_id_rsa

7.3. Decide on a project name

7.4. Decide on remote repository location

8. New project set-up

From the decisions made in the prior section, you know:

• The remote URI will be: ssh://hguser/mmghg/myHello
• The absolute path to your local hg install is: /usr/bin/hg

8.1. Create new (empty) local workspace

This is an important point!
The Autotools "Hello World" example we will use here does a "Reset defaults" to your running instance of Eclipse when it loads.
Which has the side effect of removing all of your carefully defined "Build configurations". Oops.

mszick@deb2core:~$ mkdir ecdt

8.2. Bring up Eclipse

If the Workspace Laucher is still enabled, select the new workspace;
else:

You will be shown the Welcome screen (since the new workspace did not have an Eclipse .metadata directory).

Select the C/C++ perspective if not already in that perspective.

8.3. Create the GNU Autotools example

Create the GNU Autotools Hello World example.

The automation will kick in, build all of the infrastructure, create the source program, configure it for a native build and build it.

For instance:

mszick@deb2core:~$ ecdt/myHello/src/a.out
Hello World

8.4. Create the local hg, dvcs repository

8.5. Create the remote hg, dvcs repository

There is a slight disconnect between the way the hg plug-in author(s) use Mercurial and the way it is used here.

The work-around here will be to define several "External tool" commands.
Two commands that are used once per project and one that is used at each update of the remote repository

8.5.1. Create the "Remote Init" tool

The hg remote init command, used once per project.

8.5.2. Expected Result

Expect something similar in the console window as the remote agent reply:

* * * * * * * *
sshd Agent: hgadm@173.236.167.90
ssh Client: mmghg@71.2.117.133
Collection:
    users   /home/hgadm/hg
    repos   /home/hgadm/hg
    mmghg   /home/hgadm/uhome
CommandStr: hg init /home/hgadm/uhome/mmghg/myHello
* * * * * * * *

Which, if you puzzle over it a bit, tells you the command just put the new repository in your private repository space.
It details the (local) client and (remote) agent that ran the command and lists the repository collections to which your account has access..

Note: There may be additional output. That just depends on where I am at in the on-going development of our remote agent script.

8.6. Local repository configuration

Since the current version of the hg plug-in doesn't get this correct, we get to do it ourselves.

8.6.1. Connect local and remote repositories

And since Eclipse really, really doesn't like us working in hidden directories, another one-time use custom tool:

Now that we have successfully created a new, empty file within the hidden hg repository tree; Eclipse will allow us to edit it.

Set (URI to remote and local User Identification):

[paths]
default = ssh://hguser/mmghg/myHello

[ui]
username = yourname ~lt~e-you at e-where.tld~gt~

8.6.2. Define files and/or directories to ignore

As a general rule, you don't want to push your local Eclipse environment configuration into a shared repository. That would just alter the Eclipse environment of anyone who cloned the repository.

Tell hg to ignore the Eclipse xml config files and any others that you don't want in the repository of your project.

Note: Since this is a private, remote repository you might want to track (by not ignoring) your local Eclipse environment configuration files.
That may help you keep track of how you set up your custom commands or recovering them if we stumble into another tool example that does a global "Restore Defaults" command.

Now edit it to contain the files and/or directories you do not want to track in the repository.
For example, set:

syntax: glob
.project
.cproject
.autotools
*.orig
*.rej   
*~   
*.bak   
*.out
*.i
*.s   
*.o
*.map
*.lst

8.7. Define a custom "Push" command

Once again, since this version of the hg plug-in can't seem to get this correct;
The first two commands we defined where only work-arounds used once per project.

This one will be used throughout the lifetime of the project so it will be put into the "Favorites" section of the list of external tools.

Expect:

pushing to ssh://hguser/mmghg/myHello
no changes found

Because: Since we haven't done an add and commit to the local repository, the local repository is empty and the remote repository is empty.

8.8. Get Eclipse up to speed about the local (file system) repository.

Note that your "Mercurial Repositories" view shows two repositories now, the local one and the remote.

9. Make the initial add-commit

This version of the hg plug-in has a combined add and commit function entry.

9.1. Update the local repository copy

Note: This obeys the .hgignore, we will edit that so the Eclipse xml files are added in a later step.
Note: For some reason, Eclipse-HG does not show us the "config.log" file here, but we will pick it up later.

9.2. Update the remote repository copy

Update the remote repository to match the local repository

Expect:

pushing to ssh://hguser/mmghg/myHello
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 29 changes to 29 files

10. Including the Eclipse configuration files

Since there is a lot more to do getting the cross-compile build commands defined and working.
In our private repository space, we want to track the Eclipse configuration files.

10.1. Edit the .hgignore file

10.2. Add the Eclipse xml (and config.log) files

This will add these files to the changeset which will be marked by the next "commit" action.
Note: This list now includes the config.log file. (???)

10.3. Commit (local) these additions

Note: In this example, we are also including .hgignore in the tracked files.

Now your local repository is "ahead" of your remote repository.
Which is just fine, you don't have to update your remote until your ready.

11. What more do you want?

A HowTo on setting the cross-compile build configurations maybe?