Long builds and large RAM footprint. Split gf_fnt.py in pieces?

[HugoStrand]

Dear all,

The last six months the build time and memory requirement to build the c++ wrapper for gf_fnt.py has increased drastically. On some of my cluster machines I can no longer build triqs on the login node since that particular compilations uses too much RAM and gets killed.

I would suggest that we split the methods wrapped into several smaller sub module files. This will enable parallel builds and reduce the memory footprint somewhat.

Is there some argument against this?

Best, Hugo

[parcollet]

Yes, we can do this, no issue.

[HugoStrand]

Good. Who, when, and how?

[Wentzell]

I would suggest that we split the methods wrapped into several smaller sub module files. This will enable parallel builds and reduce the memory footprint somewhat.

Agreed! The build time is indeed going through the roof for this file.

[patryk-kubiczek]

I also had problems with building gf_fnt target. The build would not even start. I was able to track the commit which made this target unable to compile, namely: c6759f4 . I had to go one commit back in order to be able to use TRIQS 2.0 on my machine.

[parcollet]

Move to cpp2py issue.

[Wentzell]

Move to cpp2py issue.

Indeed. As discussed this problem should be resolved at the level of cpp2py.
I have opened a corresponding issue for cpp2py.