Slight behavioral change in WhatModulesVTK.py (new module system)?

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Slight behavioral change in WhatModulesVTK.py (new module system)?

Elvis Stansvik
Hi Ben, all,

I quickly checked out master to see what
Utilities/Maintenance/WhatModulesVTK.py output would look like on our
code base as compared to before the module system merge. BTW many
thanks Ben for taking the effort to keep this script working!

Before (51a3c689c639e6936b0b479ffb0f7085468c0940):

All modules referenced in the files:
find_package(VTK COMPONENTS
  vtkChartsCore
  vtkCommonCore
  vtkCommonDataModel
  vtkCommonExecutionModel
  vtkCommonMath
  vtkCommonTransforms
  vtkFiltersCore
  vtkFiltersSources
  vtkGUISupportQt
  vtkIOImage
  vtkImagingCore
  vtkInteractionStyle
  vtkRenderingContext2D
  vtkRenderingCore
  vtkRenderingFreeType
  vtkRenderingFreeTypeFontConfig
  vtkRenderingOpenGL2
  vtkRenderingQt
  vtkRenderingVolume
  vtkRenderingVolumeOpenGL2
  vtkViewsContext2D
  vtkViewsCore
  vtkfreetype
  vtkkwiml
)

After (master):

All modules referenced in the files:
find_package(VTK COMPONENTS
  ChartsCore
  CommonCore
  CommonDataModel
  CommonExecutionModel
  CommonMath
  CommonTransforms
  FiltersCore
  FiltersSources
  GUISupportQt
  IOImage
  ImagingCore
  InteractionStyle
  RenderingContext2D
  RenderingCore
  RenderingFreeType
  RenderingOpenGL2
  RenderingQt
  RenderingVolume
  ViewsContext2D
  ViewsCore
  freetype
  kwiml
)

Nothing surprising, except:

  vtkRenderingFreeTypeFontConfig
  vtkRenderingVolumeOpenGL2

These are present before, but has no corresponding lines after the
merge. We make use of both.

Any ideas Ben? Is this expected or is there something fishy here.

Cheers,
Elvis
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: Slight behavioral change in WhatModulesVTK.py (new module system)?

VTK - Dev mailing list
On Fri, Jan 11, 2019 at 17:41:09 +0100, Elvis Stansvik wrote:
> Nothing surprising, except:
>
>   vtkRenderingFreeTypeFontConfig
>   vtkRenderingVolumeOpenGL2
>
> These are present before, but has no corresponding lines after the
> merge. We make use of both.
>
> Any ideas Ben? Is this expected or is there something fishy here.

If the headers are not included explicitly, the script will miss it. I
think the right way to do this would be to collect `IMPLEMENTABLE` and
`IMPLEMENTS` bits and warn that modules which have object factories may
be missing implementations (with hints as which modules implement each
module with).

There had been "magical" knowledge embedded in the script that I removed
in commit 9437f76db782c48ebaae303c0e2f472147a3e712.

Another (future) enhancement would be to have it work with an installed
VTK (or any other VTK-module providing package really) rather than
forcing a VTK source tree to be present. It also wouldn't hint modules
which were not built. This is a much harder problem since it would need
to parse and understand CMake code.

--Ben
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: Slight behavioral change in WhatModulesVTK.py (new module system)?

Elvis Stansvik
Alright, thanks for clarifying Ben. I do believe we are directly including headers though, at least for the vtkFreeTypeFontConfig case. But I'll double check.

Otherwise I'll just add these manually (keeping the magic knowledge in my head :)).

The future enhancement you mentioned sounds like a fun project. Perhaps CMake server mode can be leveraged?

Elvis

Den fre 11 jan. 2019 17:47Ben Boeckel <[hidden email]> skrev:
On Fri, Jan 11, 2019 at 17:41:09 +0100, Elvis Stansvik wrote:
> Nothing surprising, except:
>
>   vtkRenderingFreeTypeFontConfig
>   vtkRenderingVolumeOpenGL2
>
> These are present before, but has no corresponding lines after the
> merge. We make use of both.
>
> Any ideas Ben? Is this expected or is there something fishy here.

If the headers are not included explicitly, the script will miss it. I
think the right way to do this would be to collect `IMPLEMENTABLE` and
`IMPLEMENTS` bits and warn that modules which have object factories may
be missing implementations (with hints as which modules implement each
module with).

There had been "magical" knowledge embedded in the script that I removed
in commit 9437f76db782c48ebaae303c0e2f472147a3e712.

Another (future) enhancement would be to have it work with an installed
VTK (or any other VTK-module providing package really) rather than
forcing a VTK source tree to be present. It also wouldn't hint modules
which were not built. This is a much harder problem since it would need
to parse and understand CMake code.

--Ben

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: Slight behavioral change in WhatModulesVTK.py (new module system)?

Elvis Stansvik
Den fre 11 jan. 2019 kl 18:24 skrev Elvis Stansvik
<[hidden email]>:
>
> Alright, thanks for clarifying Ben. I do believe we are directly including headers though, at least for the vtkFreeTypeFontConfig case. But I'll double check.

I was wrong, we were including vtkFreeTypeTools.h but not
vtkFontConfigFreeTypeTools.h, so makes sense that the
vtkFreeTypeFontConfig is now gone, if magic has been removed.

I guess the loss of vtkRenderingVolumeOpenGL2 is also due to removed magic..?

No worries, can live without it. We could make our own script which
imports WhatModulesVTK.py and adds these in for now.

Elvis

>
> Otherwise I'll just add these manually (keeping the magic knowledge in my head :)).
>
> The future enhancement you mentioned sounds like a fun project. Perhaps CMake server mode can be leveraged?
>
> Elvis
>
> Den fre 11 jan. 2019 17:47Ben Boeckel <[hidden email]> skrev:
>>
>> On Fri, Jan 11, 2019 at 17:41:09 +0100, Elvis Stansvik wrote:
>> > Nothing surprising, except:
>> >
>> >   vtkRenderingFreeTypeFontConfig
>> >   vtkRenderingVolumeOpenGL2
>> >
>> > These are present before, but has no corresponding lines after the
>> > merge. We make use of both.
>> >
>> > Any ideas Ben? Is this expected or is there something fishy here.
>>
>> If the headers are not included explicitly, the script will miss it. I
>> think the right way to do this would be to collect `IMPLEMENTABLE` and
>> `IMPLEMENTS` bits and warn that modules which have object factories may
>> be missing implementations (with hints as which modules implement each
>> module with).
>>
>> There had been "magical" knowledge embedded in the script that I removed
>> in commit 9437f76db782c48ebaae303c0e2f472147a3e712.
>>
>> Another (future) enhancement would be to have it work with an installed
>> VTK (or any other VTK-module providing package really) rather than
>> forcing a VTK source tree to be present. It also wouldn't hint modules
>> which were not built. This is a much harder problem since it would need
>> to parse and understand CMake code.
>>
>> --Ben
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: Slight behavioral change in WhatModulesVTK.py (new module system)?

Elvis Stansvik
In reply to this post by VTK - Dev mailing list
Den fre 11 jan. 2019 kl 17:47 skrev Ben Boeckel <[hidden email]>:

>
> On Fri, Jan 11, 2019 at 17:41:09 +0100, Elvis Stansvik wrote:
> > Nothing surprising, except:
> >
> >   vtkRenderingFreeTypeFontConfig
> >   vtkRenderingVolumeOpenGL2
> >
> > These are present before, but has no corresponding lines after the
> > merge. We make use of both.
> >
> > Any ideas Ben? Is this expected or is there something fishy here.
>
> If the headers are not included explicitly, the script will miss it. I
> think the right way to do this would be to collect `IMPLEMENTABLE` and
> `IMPLEMENTS` bits and warn that modules which have object factories may
> be missing implementations (with hints as which modules implement each
> module with).
>
> There had been "magical" knowledge embedded in the script that I removed
> in commit 9437f76db782c48ebaae303c0e2f472147a3e712.
>
> Another (future) enhancement would be to have it work with an installed
> VTK (or any other VTK-module providing package really) rather than
> forcing a VTK source tree to be present. It also wouldn't hint modules
> which were not built. This is a much harder problem since it would need
> to parse and understand CMake code.

Hm, thinking a bit more, is this even possible? After installation the
headers are all in the same directory, so there's no header -> module
information available..? If an installed layout like Qt's was used
(e.g. QColor + QtGui/qcolor.h), it might have been possible. But maybe
I'm missing something..?

Elvis

>
> --Ben
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: Slight behavioral change in WhatModulesVTK.py (new module system)?

VTK - Dev mailing list
On Fri, Jan 11, 2019 at 18:42:33 +0100, Elvis Stansvik wrote:
> Hm, thinking a bit more, is this even possible? After installation the
> headers are all in the same directory, so there's no header -> module
> information available..? If an installed layout like Qt's was used
> (e.g. QColor + QtGui/qcolor.h), it might have been possible. But maybe
> I'm missing something..?

The modules list what headers are associated with them in one of their
properties (this is for wrapping tools).

--Ben
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: Slight behavioral change in WhatModulesVTK.py (new module system)?

Elvis Stansvik
Den fre 11 jan. 2019 kl 18:57 skrev Ben Boeckel <[hidden email]>:

>
> On Fri, Jan 11, 2019 at 18:42:33 +0100, Elvis Stansvik wrote:
> > Hm, thinking a bit more, is this even possible? After installation the
> > headers are all in the same directory, so there's no header -> module
> > information available..? If an installed layout like Qt's was used
> > (e.g. QColor + QtGui/qcolor.h), it might have been possible. But maybe
> > I'm missing something..?
>
> The modules list what headers are associated with them in one of their
> properties (this is for wrapping tools).

Ah yes, but what about modules that are excluded from wrapping?

Elvis

>
> --Ben
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: Slight behavioral change in WhatModulesVTK.py (new module system)?

VTK - Dev mailing list
On Fri, Jan 11, 2019 at 19:13:29 +0100, Elvis Stansvik wrote:
> Ah yes, but what about modules that are excluded from wrapping?

Indeed. They do have that property skipped. This is at line
vtkModule.cmake:2997 (give or take). I actually am not sure how third
party libraries would appear here as well since they almost always have
a separate header installation step for the header VTK exposes for them
(e.g., `vtk_hdf5.h`).

--Ben
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: Slight behavioral change in WhatModulesVTK.py (new module system)?

Andrew Maclean-3
In reply to this post by Elvis Stansvik
I am surprised and amazed this works with the new system. 
When I wrote it, it:
1) Only looked at the header files in your code and, from their name, worked out the module to use. Ad a consequence of this we had to manually include e.g. some modules like the OpenGL stuff.
2) Does detect modules excluded from the wrapping.
3) It was written before external modules were introduced so it may not properly work with them.

The intent was to provide to the user a guide as to what modules should be included so they may still have to add extras.  

Andrew




---------- Forwarded message ----------
From: Ben Boeckel <[hidden email]>
To: Elvis Stansvik <[hidden email]>
Cc: vtkdev <[hidden email]>
Bcc: 
Date: Fri, 11 Jan 2019 13:30:42 -0500
Subject: Re: [vtk-developers] Slight behavioral change in WhatModulesVTK.py (new module system)?
On Fri, Jan 11, 2019 at 19:13:29 +0100, Elvis Stansvik wrote:
> Ah yes, but what about modules that are excluded from wrapping?

Indeed. They do have that property skipped. This is at line
vtkModule.cmake:2997 (give or take). I actually am not sure how third
party libraries would appear here as well since they almost always have
a separate header installation step for the header VTK exposes for them
(e.g., `vtk_hdf5.h`).

--Ben



--
___________________________________________
Andrew J. P. Maclean

___________________________________________

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: Slight behavioral change in WhatModulesVTK.py (new module system)?

VTK - Dev mailing list
On Sat, Jan 12, 2019 at 07:13:02 +1100, Andrew Maclean wrote:
> I am surprised and amazed this works with the new system.

I updated it since it was requested here. It also turned out to be quite
helpful for determining real dependencies of things in ParaView and
examples.

> When I wrote it, it:
> 1) Only looked at the header files in your code and, from their name,
> worked out the module to use. Ad a consequence of this we had to manually
> include e.g. some modules like the OpenGL stuff.

That's pretty much true still.

> 2) Does detect modules excluded from the wrapping.

Not hard now; it's still just a keyword in `vtk.module`. Though it
doesn't do so right now.

> 3) It was written before external modules were introduced so it may not
> properly work with them.

It only cares about `vtk.module` files (just like it cared only about
`module.cmake` before. If it can find them in the path given, I don't
think it should matter too much.

> The intent was to provide to the user a guide as to what modules should be
> included so they may still have to add extras.

Yeah. I imagine the hard-coded if-then extensions were done because of
this. Doing `IMPLEMENTABLE`/`IMPLEMENTS` logic should make it work for
any module.

--Ben
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: Slight behavioral change in WhatModulesVTK.py (new module system)?

Andrew Maclean-3
Ben,
I was actually thinking of having a look at it last night because of all the changes. Thanks for already doing this!

Much appreciated.

Regards
   Andrew


On Sat, Jan 12, 2019 at 7:21 AM Ben Boeckel <[hidden email]> wrote:
On Sat, Jan 12, 2019 at 07:13:02 +1100, Andrew Maclean wrote:
> I am surprised and amazed this works with the new system.

I updated it since it was requested here. It also turned out to be quite
helpful for determining real dependencies of things in ParaView and
examples.

> When I wrote it, it:
> 1) Only looked at the header files in your code and, from their name,
> worked out the module to use. Ad a consequence of this we had to manually
> include e.g. some modules like the OpenGL stuff.

That's pretty much true still.

> 2) Does detect modules excluded from the wrapping.

Not hard now; it's still just a keyword in `vtk.module`. Though it
doesn't do so right now.

> 3) It was written before external modules were introduced so it may not
> properly work with them.

It only cares about `vtk.module` files (just like it cared only about
`module.cmake` before. If it can find them in the path given, I don't
think it should matter too much.

> The intent was to provide to the user a guide as to what modules should be
> included so they may still have to add extras.

Yeah. I imagine the hard-coded if-then extensions were done because of
this. Doing `IMPLEMENTABLE`/`IMPLEMENTS` logic should make it work for
any module.

--Ben


--
___________________________________________
Andrew J. P. Maclean

___________________________________________

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: Slight behavioral change in WhatModulesVTK.py (new module system)?

Elvis Stansvik
In reply to this post by VTK - Dev mailing list
Den fre 11 jan. 2019 kl 21:21 skrev Ben Boeckel <[hidden email]>:

>
> On Sat, Jan 12, 2019 at 07:13:02 +1100, Andrew Maclean wrote:
> > I am surprised and amazed this works with the new system.
>
> I updated it since it was requested here. It also turned out to be quite
> helpful for determining real dependencies of things in ParaView and
> examples.
>
> > When I wrote it, it:
> > 1) Only looked at the header files in your code and, from their name,
> > worked out the module to use. Ad a consequence of this we had to manually
> > include e.g. some modules like the OpenGL stuff.
>
> That's pretty much true still.
>
> > 2) Does detect modules excluded from the wrapping.
>
> Not hard now; it's still just a keyword in `vtk.module`. Though it
> doesn't do so right now.
>
> > 3) It was written before external modules were introduced so it may not
> > properly work with them.
>
> It only cares about `vtk.module` files (just like it cared only about
> `module.cmake` before. If it can find them in the path given, I don't
> think it should matter too much.
>
> > The intent was to provide to the user a guide as to what modules should be
> > included so they may still have to add extras.

Yep, we always did have to tweak it a bit and that's OK, it's very
useful nonetheless.

I run the script from time to time (not that often), just to check
that the list of modules we link against is accurate wrt to the code.

Elvis

>
> Yeah. I imagine the hard-coded if-then extensions were done because of
> this. Doing `IMPLEMENTABLE`/`IMPLEMENTS` logic should make it work for
> any module.
>
> --Ben
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: Slight behavioral change in WhatModulesVTK.py (new module system)?

Elvis Stansvik
In reply to this post by VTK - Dev mailing list
Den fre 11 jan. 2019 kl 21:21 skrev Ben Boeckel <[hidden email]>:
>
> On Sat, Jan 12, 2019 at 07:13:02 +1100, Andrew Maclean wrote:
> > I am surprised and amazed this works with the new system.
>
> I updated it since it was requested here. It also turned out to be quite
> helpful for determining real dependencies of things in ParaView and
> examples.

Maybe some day in the future, with the enhancements you had in mind
(working with installed VTK et.c.), it could be robust enough to be
used when generating the CMakeLists.txt for the examples, so they
could show "best practice" and not linking all of VTK (cf Bill's
recent thread).

Elvis

>
> > When I wrote it, it:
> > 1) Only looked at the header files in your code and, from their name,
> > worked out the module to use. Ad a consequence of this we had to manually
> > include e.g. some modules like the OpenGL stuff.
>
> That's pretty much true still.
>
> > 2) Does detect modules excluded from the wrapping.
>
> Not hard now; it's still just a keyword in `vtk.module`. Though it
> doesn't do so right now.
>
> > 3) It was written before external modules were introduced so it may not
> > properly work with them.
>
> It only cares about `vtk.module` files (just like it cared only about
> `module.cmake` before. If it can find them in the path given, I don't
> think it should matter too much.
>
> > The intent was to provide to the user a guide as to what modules should be
> > included so they may still have to add extras.
>
> Yeah. I imagine the hard-coded if-then extensions were done because of
> this. Doing `IMPLEMENTABLE`/`IMPLEMENTS` logic should make it work for
> any module.
>
> --Ben
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: Slight behavioral change in WhatModulesVTK.py (new module system)?

Bill Lorensen
There are over 1000 C++ examples. The web page for each example (and
the associated tar file) is generated automatically for each example.
To generate an example-specific components list for each example would
be a challenge. For now, I'd rather modify the templates to include pf
all the modules.

When the entire collection of examples is built, either as a Remote
module or stand-alone, it would be more of a challenge to handle the
1000 examples. I don't think it is worth the effort for what little
would be gained.

On Fri, Jan 11, 2019 at 1:07 PM Elvis Stansvik
<[hidden email]> wrote:

>
> Den fre 11 jan. 2019 kl 21:21 skrev Ben Boeckel <[hidden email]>:
> >
> > On Sat, Jan 12, 2019 at 07:13:02 +1100, Andrew Maclean wrote:
> > > I am surprised and amazed this works with the new system.
> >
> > I updated it since it was requested here. It also turned out to be quite
> > helpful for determining real dependencies of things in ParaView and
> > examples.
>
> Maybe some day in the future, with the enhancements you had in mind
> (working with installed VTK et.c.), it could be robust enough to be
> used when generating the CMakeLists.txt for the examples, so they
> could show "best practice" and not linking all of VTK (cf Bill's
> recent thread).
>
> Elvis
>
> >
> > > When I wrote it, it:
> > > 1) Only looked at the header files in your code and, from their name,
> > > worked out the module to use. Ad a consequence of this we had to manually
> > > include e.g. some modules like the OpenGL stuff.
> >
> > That's pretty much true still.
> >
> > > 2) Does detect modules excluded from the wrapping.
> >
> > Not hard now; it's still just a keyword in `vtk.module`. Though it
> > doesn't do so right now.
> >
> > > 3) It was written before external modules were introduced so it may not
> > > properly work with them.
> >
> > It only cares about `vtk.module` files (just like it cared only about
> > `module.cmake` before. If it can find them in the path given, I don't
> > think it should matter too much.
> >
> > > The intent was to provide to the user a guide as to what modules should be
> > > included so they may still have to add extras.
> >
> > Yeah. I imagine the hard-coded if-then extensions were done because of
> > this. Doing `IMPLEMENTABLE`/`IMPLEMENTS` logic should make it work for
> > any module.
> >
> > --Ben
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> https://vtk.org/mailman/listinfo/vtk-developers
>


--
Unpaid intern in BillsParadise at noware dot com
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: Slight behavioral change in WhatModulesVTK.py (new module system)?

Elvis Stansvik
Den fre 11 jan. 2019 kl 22:20 skrev Bill Lorensen <[hidden email]>:

>
> There are over 1000 C++ examples. The web page for each example (and
> the associated tar file) is generated automatically for each example.
> To generate an example-specific components list for each example would
> be a challenge. For now, I'd rather modify the templates to include pf
> all the modules.
>
> When the entire collection of examples is built, either as a Remote
> module or stand-alone, it would be more of a challenge to handle the
> 1000 examples. I don't think it is worth the effort for what little
> would be gained.

Yes, you're probably right. But I don't think it would be that great
of a challenge? I mean, the WhatModulesVTK.py script sort of works
already (with a few kinks).

But no I agree, with that many examples, it would slow down the
generation time considerably, so probably not worth it.

Elvis

>
> On Fri, Jan 11, 2019 at 1:07 PM Elvis Stansvik
> <[hidden email]> wrote:
> >
> > Den fre 11 jan. 2019 kl 21:21 skrev Ben Boeckel <[hidden email]>:
> > >
> > > On Sat, Jan 12, 2019 at 07:13:02 +1100, Andrew Maclean wrote:
> > > > I am surprised and amazed this works with the new system.
> > >
> > > I updated it since it was requested here. It also turned out to be quite
> > > helpful for determining real dependencies of things in ParaView and
> > > examples.
> >
> > Maybe some day in the future, with the enhancements you had in mind
> > (working with installed VTK et.c.), it could be robust enough to be
> > used when generating the CMakeLists.txt for the examples, so they
> > could show "best practice" and not linking all of VTK (cf Bill's
> > recent thread).
> >
> > Elvis
> >
> > >
> > > > When I wrote it, it:
> > > > 1) Only looked at the header files in your code and, from their name,
> > > > worked out the module to use. Ad a consequence of this we had to manually
> > > > include e.g. some modules like the OpenGL stuff.
> > >
> > > That's pretty much true still.
> > >
> > > > 2) Does detect modules excluded from the wrapping.
> > >
> > > Not hard now; it's still just a keyword in `vtk.module`. Though it
> > > doesn't do so right now.
> > >
> > > > 3) It was written before external modules were introduced so it may not
> > > > properly work with them.
> > >
> > > It only cares about `vtk.module` files (just like it cared only about
> > > `module.cmake` before. If it can find them in the path given, I don't
> > > think it should matter too much.
> > >
> > > > The intent was to provide to the user a guide as to what modules should be
> > > > included so they may still have to add extras.
> > >
> > > Yeah. I imagine the hard-coded if-then extensions were done because of
> > > this. Doing `IMPLEMENTABLE`/`IMPLEMENTS` logic should make it work for
> > > any module.
> > >
> > > --Ben
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> >
> > Search the list archives at: http://markmail.org/search/?q=vtk-developers
> >
> > Follow this link to subscribe/unsubscribe:
> > https://vtk.org/mailman/listinfo/vtk-developers
> >
>
>
> --
> Unpaid intern in BillsParadise at noware dot com
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://vtk.org/mailman/listinfo/vtk-developers