[GCC-XML]Function attributes.

[William A. Hoffman]

You may want to look at the work we did for ITK.
We are using GCCXML as a front end for Swig.
This allows it to take advantage of the good parsing by
gcc, and the backend language wrappers provided by SWIG.


Unfortunately, there is very little documentation right now, but if
you are interested I can help you a bit.  

You may also want to look at:
http://www.itk.org/  - a c++ kit using CSwig, see cvs version Wrapping/CSwig directory.

http://public.kitware.com/Cable/HTML/Index.html - Input format used for CSwig is defined here.

To get started here is the README from Insight/Wrapping/CSwig directory:

To use tcl or python wrapping using cswig, you will have to build
CableSwig.   CableSwig is a combination package that includes swig,
cable, and gccxml.   When built CableSwig will have three execuables:

   cswig    - the main cable swig executable, that takes an xml file from
              gccxml as input.   The xml file should be created from a cable config
              input file.

   cableidx - a program to generate index files from gccxml xml files.   The
              index files tell cswig what classes are wrapped in which libraries.

   gccxml_cc1plus - A patched version of gcc that has the -fxml option to 
                        convert c++ into xml.  

   gccxml   - http://www.gccxml.org/HTML/Index.html, the front end program to gccxml_cc1plus


To build ITK with the CSwig wrappers:

        1. checkout a copy of CableSwig  

                Simply do:

                cvs -d:pserver:anonymous at public.kitware.com:/cvsroot/CableSwig co CableSwig

                Note that no cvs login is needed here.

        1.1  IF you checkout CableSwig in the Insight/Utilities directory, then
             CableSwig will be built as part of ITK
     
        2. build CableSwig on your system.  (this step can be skipped if 1.1 was done.

        3. run cmake on ITK (ccmake or CMakeSetup)
                - turn on the show advanced values option  (t in ccmake)
                - Turn on ITK_CSWIG_TCL and/or ITK_CSWIG_PYTHON
                - run cmake configure (c for ccmake, Configure button for CMakeSetup)
                - if not found already, Set the cache entry for CSWIG to the full path to the 
                  cswig executable built in 1.  Run cmake configure again.
                  Cmake should set CABLE_INDEX and GCCXML based on the path given for CSWIG.
                  When running on windows, as long as CableSwig was configured first, cmake
                  should automatically find all of them.  If step 1.1 was followed, then
                  CSWIG, CABLE_INDEX, and GCCXML should all be set automatically.
                - generate the makefiles 

To run scripts.
        To make things easier to use, you have to set paths to the build tree of ITK.
        If using msdev or devenv, you have to include the config directory 
        (Release,Debug,MinSizeRel, RelWithDebInfo).

        Python:
                - set the PYTHONPATH variable to ITK-build/Wrapping/CSwig/Python/[Release].
                - run python and run this python command:
                         from InsightToolkit import *
        Tcl:
                - set the TCLLIBPATH variable to ITK-build/Wrapping/CSwig/Tcl/[Release|Debug]
                
                Use the following at the top of the script:

                package require Tk
                package require InsightToolkit
                package require itkinteraction

        There are a few examples in Insight/Wrapping/CSwig/Tests.


KNOWN ISSUES:
        - dependency information is not available in visual studio until
          after the first build, and cmake is run again.
        - Python must be built Release of RelWithDebInfo on windows.


At 02:38 PM 8/13/2003, Oscar Fuentes wrote:
>Hi.
>
>I intend to use GCCXML for generating interfaces between C/C++ code
>and another programming language. It seems terrific for that, much
>more accurate and simpler than SWIG.
>
>There is a missing feature, though: it's interesting to know some
>attributes for functions and, to a lesser extent, for classes. The
>calling convention is very important. It would be handy to know if a
>given function/class was marked for export with __declspec(dllexport),
>too.
>
>I know those attributes are platform-dependant, but outputting the
>contents of the attribute register on raw format should be enough. Let
>the user figure out the meaning of each bit.
>
>Regards,
>
>-- 
>Oscar
>
>_______________________________________________
>gccxml mailing list
>gccxml at gccxml.org
>http://www.gccxml.org/mailman/listinfo/gccxml