Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] What's a CLibraryFile

Hi List,

This may be a very stupid question, but bear with me...

What's a C Library File as represented by the CLibraryFileEntry class
in the new project model?  It knows about its source location and
seems to be linked to ILibraryEntry: IPathEntry#CDT_LIBRARY in the
core model which is described as:
	 * Entry kind constant describing a path entry identifying a
	 * library. A library is an archive containing
	 * consisting of pre-compiled binaries.

It looks like a normal library file  +  path? + source location?

However when it comes to managed build, the buildDefinitions schema has:

            <simpleType>
               <restriction base="string">
                  <enumeration value="string">
                  </enumeration>
                  <enumeration value="stringList">
                  </enumeration>
...
                  <enumeration value="libs">
                  </enumeration>
...
                  <enumeration value="libPaths">
                  </enumeration>
                  <enumeration value="libFiles">
                  </enumeration>
...
                  <enumeration value="undefLibPaths">
                  </enumeration>
                  <enumeration value="undefLibFiles">
                  </enumeration>
...
               </restriction>
            </simpleType>

ManagedBuild (the gnu toolchain in particular) uses 'libs' to specify
libraries to link to in the gnu toolchain.  The managedbuild.core
plugin.xml defines a libFiles option holder in the
"org.eclipse.cdt.build.core.prefbase.cfg" but this doesn't seem to be
referenced anywhere.

The problem is that cdt.core doesn't (currently) have a handle on the
managedbuild libs, though it does have a handle on libPaths and
libFiles.  CDT.core referenced project automatically propagates the
external settings exports from one configuration to the referencee.
This works fine for library paths, include paths, and macrs, but
doesn't work for 'libs' as they're not tied to ICSettingEntry.

So the question really is: How are libs different from libFiles?  Is
it worth shoe-horning libs into libFiles; or making libs into a first
class ICLanguageSettingEntry type?

It looks like they are one and the same -- or similar enough
semantically to be coalesced -- but that doesn't explain why they're
different types in the buildDefinitions schema... (The managedbuild
extensibility document is unhelpful on this:
"... There are also four specialized cases of list options,
includePath, definedSymbols, libs, and userObjs to manage the list of
paths to search for header files, the defined preprocessor symbols,
external libraries to link against, and object module to link in
respectively. ..."

Any ideas / pointers?

Cheers,
James


Back to the top