Back to the main page.
Bug 301 - ensure that the mex compile scripts are consistent throughout
| Status | CLOSED FIXED |
| Reported | 2010-12-13 09:21:00 +0100 |
| Modified | 2011-11-11 11:19:36 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P3 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Robert Oostenveld - 2010-12-13 09:21:14 +0100
The main ft_compile_mex works very well. It would be nice if the seperate modules (especially the ones that are substantial, i.e. forward and fileio) also have compile script. These compile scripts are meant for people who download only the specific section of fieldtrip (from pub/fieldtrip/modules). Perhaps we should make a ft_compile_fileio ft_compile_forward and ft_compile_xxx for each module that contains mex files. Of course the consequence is that ft_compile_mex (the main one) and ft_compile_fileio would do some double work. I don't see that as a problem, especially because the script is makefile-like anyway. The compile function inside uint64 and config can remain as they are, since they are hidden from the regular users.
Robert Oostenveld - 2010-12-13 09:23:20 +0100
PS this request is inspired by the neurodebian packaging of fieldtrip, a potential "fieldtrip-fileo" debian package should be self contained and should be source only, which means that a clear compile instruction (the script) should be included to make the fieldtrip-fileio binary package.
Stefan Klanke - 2010-12-13 17:24:25 +0100
Would you favor the compile scripts to be completed independent (and thus duplicating code), or share some private subfunctions (with externals etc.)? In the latter case, should ft_compile_mex call ft_compile_fileo etc.?
Robert Oostenveld - 2010-12-13 17:46:24 +0100
I don't have a strong preference.
Stefan Klanke - 2010-12-14 10:28:47 +0100
I added two helper functions "add_mex_source" and "compile_mex_list" in fieldtrip/private, with externals in forward/private and fileio/private. There are now ft_compile_mex ft_compile_fileio ft_compile_forward The first one compiles the files in fileio + forward as well, but without using the 2nd + 3rd function, simply because this would list the files differently, e.g., "Skipping up-to-date MEX file fileio/private/read_24bit" would become "Skipping up-to-date MEX file private/read_24bit" if I call ft_compile_fileio from within ft_compile_mex. Now, the remaining problem is how to handle the externals properly. We need some MEX files in fieldtrip/private and inverse/private which normally get pulled in from forward/private, but this isn't possible for a source-only distribution. We could copy the MEX files within the compile script for fieldtrip/private, and have externals for the source files instead for inverse/private, so that this is still independent. But this clashes a bit with our internal usage of the SVN externals for the developers, I fear.
Robert Oostenveld - 2011-10-06 20:25:47 +0200
this bug has been open and untouched for a long time. We now have ft_compile_mex and the common fieldtrip/src directory containing the primary copy of the c code and mex file. The secondary copy is maintained on the svn server with the svn autosync=yes property.