Timeline for Byte-compilation of a multi-file package: "the function is not known to be defined"
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 7, 2014 at 21:19 | vote | accept | T. Verron | ||
| Nov 7, 2014 at 21:08 | comment | added | T. Verron | And thanks for the refactoring suggestion, this indeed would work. | |
| Nov 7, 2014 at 21:07 | comment | added | T. Verron |
As I mentioned in my initial answer, your first workaround works fine, but it rather tedious. The second one sounds promising, but it will be a bit more complicated: the statements will need to be wrapped in eval-when-compile's, and the packages will need to set their variable to nil at the end of the file (because all the files are compiled in a single session). It also has the benefit of showing me why exactly recursive loading is more complicated to avoid than repeated loading.
|
|
| Nov 7, 2014 at 21:01 | comment | added | Malabarba |
@T.Verron Yes, I worked on the assumption that your example wasn't completely accurate, and I offered workarounds. Still, I stand by my statement that the package can be better designed. In your realistic example, there's no reason why the file who assembles everything together should also be the one to define variables and groups. Make an extra file which contains these definitions (such as test-variables), and this file won't have to require any of the others.
|
|
| Nov 7, 2014 at 20:46 | comment | added | T. Verron |
The realistic situation is a package where the main file declares some stuff (variables such as a mode map, executable paths, customize group), requires other files providing a bunch of functions for the package, and assembles it all together (at least into a -mode function). The example is a toy example, having it use test-fun2 would not change the problem at all.
|
|
| Nov 7, 2014 at 11:52 | history | answered | Malabarba | CC BY-SA 3.0 |