[vtk-developers] Solved - cmVTKWrapTcl2Command.c

[John Biddiscombe]

There seem to be three reasons for the dodgy behaviour

1) some instances of
char *var = malloc(...)
followed by
info->CAPI->Free(var);

and also
  concrete = (char **)malloc(sizeof(char *)*newArgc);
  concrete[numConcrete] = strdup(srcName);
  //....
  info->CAPI->FreeArguments(numConcrete,concrete);

where structures are being allocated in the MS compiled CMake, and freed in
the Borland compiled dll. To some extent I'm getting crashes even when using
MS and MS, but I may have linked something wrong.


2) A very nasty little one that was hard to find...(this was in my code, but
it may appear elsewhere, so it's worth mentioning)

  // fetch a char pointer from a cmSourceFile object
  const char *cdir = info->CAPI->SourceFileGetFullPath (file);
  // set up the tcl wrapped object using using
  info->CAPI->SourceFileSetName2(file, newName, cdir, "cxx",0);
  // later do something with cdir, but hang on, cdir actually points to the
  // std::string var.c_str() pointer and was invalidated when
  // the string was overwritten in the SourceFileSetName2 call

3) I'm told, but can't find it in writing, that MS vis Studio uses a
structure packing size of 4 by default, but Borland by default uses 8, so
maybe the whole of cmCPluginAPI should to be wrapped in
#pragma pack(push, 4)
#pragma pack(pop)
or something appropriate like byte alignment. I don't know if these pragmas
are valid on other compilers...

(Not sure if this was causing trouble, but I'll mention it anyway)

Open to correction on any of the above points. I've fixed the WrapTcl2
command, but I suspect similar problems exist in the other wrappers and may
crop up when people start mixing compilers. Relative paths are now working
in the tcl wrap command. Phew!

yours

JB

NB. One bug left
Set_Source_File_Properties(
  obsolete/AbstractCoverageFilter
  ABSTRACT
)
doesn't work properly. I'll look into this, but it seems it doesn't
correctly set the flag. If I leave out the obsolete/ path - it fails when
CMake executes and can't find the file (which is fair enough)...