Having butted heads with a few of the issues associated with the plugin
parsing algorithms I know a bit about how Eclipse handles the plugin.xml
files.
In general, the plugin.xml files are loaded on startup only unless you
install a new feature via the update mechanism and ask it to try to
startup the new plugins in place.
The first time you run Eclipse, all plugin.xmls are parsed. Once the
plugin.xml file is read in it is cached.
Eclipse will notice updates to plugins thereafter only if:
a) The eclipse/plugins directory has changed (i.e. its last modified
time has changed ). On most filesystems this works great as if you add
a plugin under eclipse/plugins that actually modifies the parent
directory. On some filesystems e.g. FAT32 this does not happen though
and Eclipse will not notice that you've added anything unless you
manually update the modified time of the eclipse/plugins directory. I
do not know offhand an exhaustive list of which filesystems this holds
true for but you can test this by creating a directory and then adding a
file to it and seeing if the modified time of the directory changed.
There is a bugzilla filed against this somewhere but I recall that the
owners essentially didn't see it as something they would fix anytime
soon as they would have to rethink the whole plugin parsing algorithm.
They don't want to be parsing all the plugins every time you start
eclipse because startup time would be atrocious.
b) The plugin is new or the version specified in the plugin.xml is
greater than what it was previously. If you update the plugin.xml
without revving the plugin, it will not be reparsed.
___________________________________________
Chris Recoskie
Software Designer
IDE Frameworks Group
Texas Instruments, Toronto
-----Original Message-----
From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On
Behalf Of Treggiari, Leo
Sent: Friday, March 18, 2005 1:50 PM
To: cdt-dev@xxxxxxxxxxx
Subject: RE: [cdt-dev] Managed Make Solutions, GCC and Linking
problems
Hi rob,
Make sure this is on a single line:
commandLinePattern="${COMMAND} ${FLAGS} ${OUTPUT_FLAG}
${OUTPUT_PREFIX} ${OUTPUT} ${INPUTS}">
Also, I don't know what algorithm Eclipse uses for re-loading the
plugin.xml files. For example, I don't know whether Eclipse notices
that a plugin.xml file has changed, or whether it has stored the
information from the plugin.xml in its configuration data and won't
read
the file again. Maybe someone else on this mailing list knows...
In the past, I've just deleted my "configuration" and "workspace"
directories, but there may be a less disruptive way to do this...
Regards,
Leo
-----Original Message-----
From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On
Behalf Of Rob Styles
Sent: Friday, March 18, 2005 1:02 PM
To: cdt-dev@xxxxxxxxxxx
Subject: RE: [cdt-dev] Managed Make Solutions, GCC and Linking
problems
Hey Leo,
Thanks for the response - this looks just like what I need.
What I've done is edited that so that each tool element looks
something
like this:
<tool
id="cdt.managedbuild.tool.gnu.c.compiler.exe.debug"
superClass="cdt.managedbuild.tool.gnu.c.compiler"
commandLinePattern="${COMMAND} ${FLAGS} ${OUTPUT_FLAG}
${OUTPUT_PREFIX} ${OUTPUT} ${INPUTS}">
<option
...
</option>
...
</tool>
This looked like it should work to me, based on your instructions and
the XML. I found 12 osLists with solaris in and I found 33 places to
add
commandLinePattern in.
However - it doesn't seem to have made the make files change :-( I
deleted the whole Debug folder just in case and it's re-created it,
but
without a space between -o and output.
Any thoughts?
Thanks a lot
rob
-----Original Message-----
From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On
Behalf Of Treggiari, Leo
Sent: 18 March 2005 17:24
To: cdt-dev@xxxxxxxxxxx
Subject: RE: [cdt-dev] Managed Make Solutions, GCC and Linking
problems
Hi rob,
The GCC tool-chain definitions can be found in
org.eclipse.cdt.managedbuilder.ui\plugin.xml.
Unfortunately, Solaris does not have a separate tool definition - the
definition is shared with linux, hpux, aix, qnx. But, if you want to
make it work for your system:
1. Search for Solaris. You should find 6 Configuration definitions
that specify Solaris in the osList.
2. For each compiler Tool definition within each of the Configuration
objects,
O Add the following attribute:
commandLinePattern="${COMMAND} ${FLAGS} ${OUTPUT_FLAG}
${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}"
(There should be a space between ${OUTPUT_FLAG} and ${OUTPUT_PREFIX},
but on a single line.)
Regards,
Leo
-----Original Message-----
From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On
Behalf Of Rob Styles
Sent: Friday, March 18, 2005 12:00 PM
To: cdt-dev@xxxxxxxxxxx
Subject: RE: [cdt-dev] Managed Make Solutions, GCC and Linking
problems
Ok, I think I've got it down to the makefile content in subdir.mk
for each of the .c sources we get:
gcc -O0 -g3 -Wall -c -fmessage-length=0 -v -o$@
../source/getMessage.c
Now, this passes through to the assembler as:
/usr/ccs/bin/as -V -Qy -s -xarch=v8 -osource/main.o
/var/tmp//ccDPIZmN.s
The problem appears to be that the usage specifies [-o objfile]. If I
run the compile manually to generate the .s then run the assembler
manually with:
/usr/ccs/bin/as -V -Qy -s -xarch=v8 -o source/main.o
/var/tmp//ccDPIZmN.s
NB: the space between -o and source/main.o, then everything works
fine.
I tried then editing the subdir.mk to add the space into the gcc
command
line and that makes everything work fine.
Does it make sense, then, to alter the templates that CDT is using to
generate my managed makefiles? If so, does anyone know where I can
find
them?
thanks
rob
-----Original Message-----
From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On
Behalf Of Rob Styles
Sent: 18 March 2005 15:17
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Managed Make Solutions, GCC and Linking problems
Hey All,
I've got a problem with a managed make project under:
CDT 2.1.0 (Eclipse 3.0.1)
Solaris 2.8
gcc version 3.4.2;
/usr/ccs/bin/as: Sun WorkShop 6 2003/12/18 Compiler Common 6.0 Patch
114802-02
I've put together a quick HelloWorld with just two source files and
one
header. The main calls a getMessage function which returns "Hello
World"
which main then prints out to console.
This doesn't build for me :-(
Build output and code below. It appears (at very much face value) that
the assembler isn't being given any filenames to, well, assemble.
Can anyone help me out with some guesses at the settings I've missed?
I'm running with defaults in all the C/C++ Build > Tool Settings :-(
Thanks
Rob
____________________________________________________________________
**** Full rebuild of configuration Debug for project HelloWorld ****
make -k clean all
rm -rf source/getMessage.o source/main.o source/getMessage.d
source/main.d HelloWorld
Building file: ../source/getMessage.c
gcc -O0 -g3 -Wall -c -fmessage-length=0 -osource/getMessage.o
../source/getMessage.c
/usr/ccs/bin/as: error: no input filename given
usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-f[O][if]#] [-q] [-s]
[-S] [-K {pic,PIC}] [-o objfile] [-L] [-T]
[-P [[-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
[-m [-Ym,path]] [-n] [-ul] [-xF] [-xarch=v7] [-xarch=v8]
[-xarch=v8a] [-xarch=v8plus] [-xarch=v8plusa] [-xarch=v8plusb]
[-xarch=v9] [-xarch=v9a] [-xarch=v9b] [-xcode={pic13,pic32}]
file.s...
make: *** [source/getMessage.o] Error 1
Building file: ../source/main.c
gcc -O0 -g3 -Wall -c -fmessage-length=0 -osource/main.o
../source/main.c
/usr/ccs/bin/as: error: no input filename given
usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-f[O][if]#] [-q] [-s]
[-S] [-K {pic,PIC}] [-o objfile] [-L] [-T]
[-P [[-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
[-m [-Ym,path]] [-n] [-ul] [-xF] [-xarch=v7] [-xarch=v8]
[-xarch=v8a] [-xarch=v8plus] [-xarch=v8plusa] [-xarch=v8plusb]
[-xarch=v9] [-xarch=v9a] [-xarch=v9b] [-xcode={pic13,pic32}]
file.s...
make: *** [source/main.o] Error 1
make: Target `all' not remade because of errors.
Build complete for project HelloWorl
main.c__________________________________________________
#include <stdio.h>
#include <stdlib.h>
#include "getMessage.h"
int main(int argc, char *argv[]) {
printf((char*)getMessage());
exit(0);
}
getMessage.c____________________________________________
char* getMessage() {
return "Hello World";
}
getMessage.h____________________________________________
char* getMessage();
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
