All SWIG files are install targets so any binary packages will include them there which would be sufficient I guess.
Should we still provide them in the tar balls, or should they be autogenerated through the CMake interface? J On 05/15/2013 12:44 PM, Garth N. Wells wrote: > Since these files are only needed by the Python interface, which > requires SWIG and is not useful without UFL and FFC being installed, I > think moving the SWIG-generated files to the build directory would be > good. > > We would need a mechanism for including the files in the source > directories to make the Debian and Mac packages. > > Garth > > On 13 May 2013 08:58, Johan Hake <[email protected]> wrote: >> Agree to do this in build directory. I can have a look at that, but not >> atm. >> >> Also letting CMake take responsibility (with appropriate build >> dependencies in place) of the (re-)generation of the SWIG interface >> could also solve problem of when to generate. Not sure how difficult >> that would be. >> >> J >> >> On 05/13/2013 09:50 AM, Anders Logg wrote: >>> One thing Benjamin mentioned to me the other week was a suggestion >>> that all files that we generate should be generated inside the build >>> directory - we should never generate files inside the source tree. >>> >>> If we could get that in place, it would solve this issue since then >>> the generated and differing files would always reside under >>> build.user.foo (created automatically using the cmake.local script). >>> >>> -- >>> Anders >>> >>> >>> On Mon, May 13, 2013 at 08:46:12AM +0100, Garth N. Wells wrote: >>>> The files have all already been removed from master for the very >>>> reason that it made branching problematic. Just merge the changes into >>>> maint. >>>> >>>> Whether or not you need to regenerate is completely at your >>>> discretion. I would not want to automate this when switching since it >>>> introduces an overhead that is often unnecessary. >>>> >>>> Garth >>>> >>>> On 13 May 2013 08:36, Martin Sandve Alnæs <[email protected]> wrote: >>>>> That would fix the first issue. My second question still stands. Will >>>>> I have to regenerate each time I switch branches to be safe? IMHO it >>>>> would be better to regenerate when interface changes are done, and >>>>> then commit it in the relevant branch. >>>>> >>>>> Martin >>>>> >>>>> On 13 May 2013 09:34, Anders Logg <[email protected]> wrote: >>>>>> On Mon, May 13, 2013 at 09:31:46AM +0200, Martin Sandve Alnæs wrote: >>>>>>> Two problems. >>>>>>> >>>>>>> >>>>>>> When checking out the maint branch, the .i files are attempted >>>>>>> overwritten, but since they are not part of the repository git >>>>>>> refuses: >>>>>>> error: The following untracked working tree files would be overwritten >>>>>>> by checkout: >>>>>>> dolfin/swig/modules/common/dependencies.txt >>>>>>> dolfin/swig/modules/common/module.i >>>>>>> ... >>>>>>> This is a temporary problem until next release because these files >>>>>>> have not been removed in maint consistently with the master branch. >>>>>>> >>>>>>> >>>>>>> When checking out another branch, the generated .i files may not be >>>>>>> consistent with the source code. This is of course the same as when >>>>>>> something is edited. How do I know when to regenerate? >>>>>> >>>>>> Can't we just remove them from maint? >>>>>> >>>>> _______________________________________________ >>>>> fenics mailing list >>>>> [email protected] >>>>> http://fenicsproject.org/mailman/listinfo/fenics >>> _______________________________________________ >>> fenics mailing list >>> [email protected] >>> http://fenicsproject.org/mailman/listinfo/fenics >>> >> _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
