Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Managed Make Solutions, GCC and Linking problems

Sorry, to be clearer, both a) and b) must be true for it to pickup the
change.

___________________________________________
 
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 Recoskie, Chris
> Sent: Friday, March 18, 2005 2:13 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: RE: [cdt-dev] Managed Make Solutions, GCC and Linking
problems
> 
> 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


Back to the top