Cint Reflex and CMake

Hi Sascha,

Zelzer Sascha wrote:
> I started using Reflex in one of my projects and since I am using CMake
> as build system generator, I found the Reflex CMake macros very handy to
> generate the dictionary code. My question now is, since Cint uses
> Reflex, are there any plans to introduce CMake macros to ease the use of
> Cint, especially the call to makecint (if not, I would write my own
> wrapper macros)?

I would like to see a CMake base build system for CINT altogether - not
just macros for makecint. Would you volunteer for a first shot? Building
CINT is just a matter of compiling the sources - except for its
dictionaries (src/dict and "cintdlls") and a few platform specific
includes (iosenum, include/types.h etc).

> Second, if I now use makecint to get access to my compiled classes
> inside the interpreter, do I also automatically gain access to the type
> information via the static Reflex::Type methods inside my compiled
> library code?

If you use CINT7 (i.e. core == new): yes. CINT5 (core == old) has no
connection to Reflex.

Cheers, Axel

Hi Axel,

thanks for the information. If my schedule permits it, I will try to write some CMake files for CINT in the next couple of weeks. If it works well, are you interested in applying a patch to your repository, so that the maintenance of the CMake scripts could be handed over to someone in your group who has write access to it?

Regards,

Sascha

-----Ursprüngliche Nachricht-----
Von: Axel Naumann [mailto:Axel.Naumann@...]
Gesendet: Sonntag, 28. Dezember 2008 14:19
An: Zelzer Sascha
Cc: cint@...
Betreff: Re: [CINT] Cint Reflex and CMake

Hi Sascha,

Zelzer Sascha wrote:
> I started using Reflex in one of my projects and since I am using CMake
> as build system generator, I found the Reflex CMake macros very handy to
> generate the dictionary code. My question now is, since Cint uses
> Reflex, are there any plans to introduce CMake macros to ease the use of
> Cint, especially the call to makecint (if not, I would write my own
> wrapper macros)?

I would like to see a CMake base build system for CINT altogether - not
just macros for makecint. Would you volunteer for a first shot? Building
CINT is just a matter of compiling the sources - except for its
dictionaries (src/dict and "cintdlls") and a few platform specific
includes (iosenum, include/types.h etc).

> Second, if I now use makecint to get access to my compiled classes
> inside the interpreter, do I also automatically gain access to the type
> information via the static Reflex::Type methods inside my compiled
> library code?

If you use CINT7 (i.e. core == new): yes. CINT5 (core == old) has no
connection to Reflex.

Cheers, Axel

Hi Sascha,

Zelzer Sascha wrote:
> thanks for the information. If my schedule permits it, I will try to
> write some CMake files for CINT in the next couple of weeks.

That would be fantastic!

> If it
> works well, are you interested in applying a patch to your
> repository, so that the maintenance of the CMake scripts could be
> handed over to someone in your group who has write access to it?

Of course - that would be the plan if you agree to publish the CMake files!

Cheers, Axel.

Hi,

I made some progress with the CMake build system and am looking now at
the makecint tool. I plan to replace it with CMake macros, but would
like to ask a few questions before:

- The make file generated my makecint calls cint to generate a source
file. What is the relation to Reflex here (both seem to generate type
information)? More precisely, could cint be adapted so it could
interface with the source code (dictionaries) generated by Reflex? Or is
cint generating some stuff Reflex can't?

- Will the introduction of a CMake macro which calls cint to generate
the sources handle all things makecint was designed for? Meaning, can it
be a full replacement?


Thanks,
Sascha

Hi Sascha,

> - The make file generated my makecint calls cint to generate a source
> file. What is the relation to Reflex here (both seem to generate type
> information)?

The 'pure' Reflex equivalent is a call to genreflex.   Currently both
are not completely
equivalent (they will eventually be).   Either way, there will still be
a need to call a
dictionary generator.

The original idea of makecint was to be able to generate the 'makefile'
that can be used
to generate the dictionary, compile it and link it.   So I think that
you could replace
makecint by a CMake 'file' generator that relies on existing CMake
macros (i.e. to be
a full replacement you would still need to generate _something_).

Cheers,
Philippe


Zelzer Sascha wrote:

Hi,

please see my comments below.

Yes, it is clear that some kind of dictionary generation is needed. I was just wondering if there are plans to rely on one way only (i.e. only Reflex, no cint -c calls).

I asked the following question before, but just to make sure: If I generate all dictionaries with a call to "cint -c", will I be able to access the type information via Reflex::Type objects? Or do I have to generate additional dictionaries with genreflex?

Regards,
Sascha
 

> The original idea of makecint was to be able to generate the 'makefile'
> that can be used
> to generate the dictionary, compile it and link it.   So I think that
> you could replace
> makecint by a CMake 'file' generator that relies on existing CMake
> macros (i.e. to be
> a full replacement you would still need to generate _something_).

Hi Sascha,

On 2009-01-14 16:32, Zelzer Sascha wrote:
Yes, these plans exist, but differently: we don't want to call genreflex (which
requires GCCXML etc); instead, cint will be called with a different parameter
for the dictionary type. So for all you are concerned this should not be relevant.

> I asked the following question before, but just to make sure: If I generate
> all dictionaries with a call to "cint -c", will I be able to access the type
> information via Reflex::Type objects? Or do I have to generate additional
> dictionaries with genreflex?

cint -c is sufficient. Also once you have it we can (finally!) get rid of the
cintdll scripts and use your CMake macro instead also for those.

Cheers, Axel.

Hi again,

Okay, I see. So would you be happy if the CMake macro could generate one
dll including all the generated sources for one library or do you want
to keep one dll for each source/header file? Looking at the stl dlls, I
could fuse climits.dll, complex.dll, etc. into one stl.dll for example.

Regards,
Sascha

Hi,

This could be an option.  However in many case, you want to keep them
separate so that
you don't have to load the portion you do not need (for example being
able to load \
only vector.dll if you are not using map).

Cheers,
Philippe

Zelzer Sascha wrote: