[cdt-dev] Re: What's a CLibraryFile

[James Blackburn <jamesblackburn@xxxxxxxxx>]

Well there's a bug at least where the implementers: Alain, Mikhail and
Leo talk about just this... :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=100844

2009/10/24 James Blackburn <jamesblackburn@xxxxxxxxx>:
> 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
>