IdeasForTheFuture

Ideas for the Future

This is some space in which we can jot down our ideas for potential future features. Nothing here is guaranteed to happen but it is good to note down concepts as they occur.

API Directives

The design as it stands allows for a "zero configuration" mode of operation. In this mode Fab just locates all the source in the subtree rooted at the currently selected directory. It then finds any Fortran program units or C int main(int argc, char **argv) functions. It then recurses through their dependencies to find every object which should be linked to make an executable.

There is no similar process which would allow us to infer the members of a library as neither Fortran or C source has any intrinsic knowledge of which objects belong in a library. That has to be provided externally as a list in some sort of configuration file. What this list is effectively doing is defining the API of the library by selecting which objects are linked into it.

What might be possible (and desirable?) is to use in source directives, in the recognised style, to identify variables, procedures and types which make up the API. Then "zero configuration" could intuit how to link the library. What's more, if the concept of a unique library name were included in these directives it would be possible to build multiple libraries from the same source tree. Even have objects appearing in more than one.

Consider an example where there is to be a normal library containing a class and a procedure. There is also to be a special library which holds the same class and a global variable but not the procedure.

!$FAB API(special)
integer :: some_global

!$FAB API(normal, special)
type :: my_type
  ...
contains
  ...
end type

!$FAB API(normal)
subroutine a_thing()
  ...
end subroutine

#pragma fab api(special)
static int some_global;

#pragma fab api(normal, special)
class my_class {
  ...
}

#pragma fab api(normal)
void a_thing() {
  ...
}

Obviously names and syntax are up for debate.

One concern is that this is repeating the mistake of the "dependson" comments used by FCM. This is true in so much as it provides additional information not provided by the standard language. However it differs in that it uses the existing recognised means, be they specified or common usage. It is very clear to which tool the information is intended as it is named. Consider OpenMP as an example of where this is already done.