I am trying to write T4 template to create wrapper classes for classes created by SubSonic 3 (implementing IActiveRecord). But when I compile my template I get following error:
Compiling transformation: Metadata file 'SubSonic.Core' could not be found
I'm including SubSonic.Core in my settings file. <## assembly name="SubSonic.Core" #> and then importing the namespaces like <## import namespace="SubSonic.Schema"#> and <## import namespace="SubSonic"#>
What I'm doing wrong? Do I need to put SubSonic.Core.dll into GAC?
Have you tried putting .dll at the end of the assembly name?
<## assembly name="SubSonic.Core.dll" #>
(Make sure that SubSonic.Core.dll is in the same directory).
There is an article on the T4 Assembly directive that may help you:
http://www.olegsych.com/2008/02/t4-assembly-directive/
Related
I've got a c++ project called core that compiles successfully and produces a dll and a lib file when compiled on Windows. Now I need to import functionality from core in another project called main. core has a file called core.module.ifc:
export module core
export import :mod
export import :egx
export import :utils
In my main project, I have a single demo.cpp which looks like this:
#include "someOtherLib.h"
import std.core // error occurs here
import core
.....
some other code
However, main does not compile with error:
1>C:\Users\main\Desktop\Projects\demo\src\demo.cpp(8,11): error C2230: could not find module 'core'
I am using VS 16 2019 to compile, with std::c++latest and platform toolset v142. The core.lib file is correctly given as input to the linker in the project's properties. From what I understand, the compiler has no way of knowing that core is an outside library and looks for export module core in the demo project (which obviously fails) and requires a file that has all the declarations of the core lib. Am I correct on this assumption? If so, how would this file look?
So I believe a summary of my question would be, how do I import a module that is exported from a library into my project?
I've recently discovered the wonders of TMB and I'm working on a package which would ideally include TMB c++ templates in it for rather computationally expensive models.
I'm assuming that there's a possibility of:
Automatically compiling the TMB source code on package install
but I can't find any clear guidelines in the TMB documentation regarding this. As of now, my alternative is to write functions that compile the TMB code upon the first call of a function which uses an uncompiled class... but I have a feeling there are nicer ways to do this.
Has anyone successfully included TMB functions within another package and could point me in the direction of relevant documentation or examples?
With a bit more searching i finally found my answer in this thread. I guess I missed it because the resolutions it details were moved to the wiki page titled development, where the content is specifically targeted for users wishing to contribute to the development of TMB, whereas I just want to distribute code which incorperates TMB.
To summarize, the thread suggests some changes which I adopted like this (myPkg should be the name of your package):
src/
Place your .cpp template in mypkg/src. This will then be automatically compiled by R when you build your package.
DESCRIPTION
Add these lines to your description file so R has all the tools necessary to compile the model template.
Depends: TMB, RcppEigen
LinkingTo: TMB, RcppEigen
R/roxygentags.r
Now we need to add our TMB template to the namespace file. We can do this easily through roxygen by making a dummy file like so:
#' Roxygen commands
#'
#' #useDynLib myPkg
#'
dummy <- function(){
return(NULL)
}
The dummy function is just an excuse to have the tag #useDynLib myPkg somewhere in my source code where I wont mess with it. This tag will populate your NAMESPACE with useDynLib(myPkg)... and as I understand, this loads the shared libraries upon loading the package for you.
Calling the function in your package:
Finally, when calling MakeADFun, set DLL="myPkg". With this setup, you can compile a single TMB model into your package. This is because the content compiled in your ./src/ folder will automatically be renamed according to your package name, thus you cannot create uniquely named models.
EDIT: Solution for distributing multiple DLLs
After some more searching (same thread as referenced above)... I realized that solution described in the official wiki (and detailed above) is only relevant for distributing a single dll (i.e. a single TMB model).
If you want to distribute multiple TMB models in a package, you'll have to use your own makefile. I've given a more detailed description in my blog, so I'll only briefly describe the steps here with regard to how they differ from the previous steps I described.
src/Makefile
You'll have to define your own Makefile (or Makefile.win for windows users) and drop it in your src/ directory. Here's an example that works for me:
all: template1.so template2.so
# Comment here preserves the prior tab
template1.so: template1.cpp
Rscript --vanilla -e "TMB::compile('template1.cpp','-O0 -g')"
template2.so: template2.cpp
Rscript --vanilla -e "TMB::compile('template2.cpp','-O0 -g')"
clean:
rm -rf *o
For windows, replace so, with dll, and use the relevant compiler flags (for debugging). See ?TMB::compile for info regarding compiler flags for debugging.
R/roxygentags.r
This is slightly different than above:
#' Roxygen commands
#'
#' This is a dummy function who's purpose is to hold the useDynLib roxygen tag.
#' This tag will populate the namespace with compiled c++ functions upon package install.
#'
#' #useDynLib template1
#' #useDynLib template2
#'
dummy <- function(){
return(NULL)
}
Using your models in the package
Finally, the above changes will compile multiple uniquely named TMB templates and load them into the namespace. To call these models in your package, here's an example:
obj <- MakeADFun(data = data,
parameters = params,
DLL="template1",
inner.control = list(maxit = 10000),
silent=F)
Tips...
I had issues when I tried compiling this on a windows machine... it turned out to be related to not properly cleaning the src folder and I had old linux compiled files stuck in there. If you have compilation issues, its worth manually cleaning out the residual files in your src/ directory from previous builds... or perhaps someone can give some good advice on writing a better make file!
If you want access to the CppAD library with the additional code from TMB (which is quite substantial!) then you can use the WITH_LIBTMB macro variable as I do in this header here. This will allow you to have multiple .cpp files which you can compile separately. Importantly, you only need to compile the code from the TMB header once using a file like this which #includes the TMB.hpp header without defining WITH_LIBTMB.
This reduces the compilation time substantively as you can compile each .cpp on its own without all the code which is declared in TMB.hpp. Moreover, you can also use the code with Rcpp if you undefine and define a few macros as I do in the link.
You can also have one file which can used by TMB::MakeADFun. It requires a bit of manual work but can be done whilst also using Rcpp by using Rcpp::compileAttributes and changing the created file called RcppExports.cpp to instead be named init.cpp and then include these additional lines in the CallEntries array and R_init_survTMB function:
CallEntries array.
R_init_survTMB function.
Note on using Rstudio
Rstudio calls Rcpp::compileAttributes (or something similar) each time you build. Hence, you cannot use this. One way around this is to create a custom build script similar to the one here. It essentially calls R CMD INSTALL after having removed the RcppExports.cpp file created by Rcpp::compileAttributes. I also like to run the tests by calling devtools::test() but you can remove this if you like.
In my work I have seen there is a test project for typescript project(with ts file app1.ts).It is using Chutzpah as test runner.In its config file it has reference path to the the js file generated by ts compiler(app1.js).In test project there is a file appTests.ts in which there is a import statement to import app1.ts.As per my knowledge both are doing same referencing to the same file,But what chutzpah runner is doing with this reference.
The chutzpah_reference is an old way to let Chutzpah know that your file is referencing another one just for testing. You would use this if you knew when building for real deployment you handled this differently. That said, you should not use this anymore and just make use of a Chutzpah.json file.
I can export a project to a template just fine, however, things are missing in the new project.
My goal is to create a template for code testing that requires some custom project/build/linking configurations. I found that I can preserve all these custom settings in an exported project. In addition to these settings is a directory that contains a .dll and .lib file. I have my paths set up as $(ProjectDir)\supp\tester.dll
-and-
$(ProjectDir)\supp\tester.lib
in their respective locations for linking.
The problem is that when I export the project as a template, and create a new project from the template, I am missing the tester.lib file in the supp directory. I even tried unzipping the template file and adding the tester.lib file back to SUPP, and rezipping it. I still cannot create a project from the template that includes the tester.lib file. Only the tester.dll file is created.
Do I have to set something up to tell VS to include this file in the template??
Thanks!
I got it working, although I am not sure if it was the most correct solution.
I had to export my project, unzip the resulting template, copying the tester.lib file to the unzipped file, and manually edit the templates .vstemplate file by adding:
<ProjectItem ReplaceParameters="false" TargetFileName="tester.lib">tester.lib</ProjectItem>
under the <Project><\Project> section. I then rezipped the files and put it in the Templates directory in the Visual Studios user area. Project I create with this template now include both the tester.dll and tester.lib files.
When referencing an assembly inside a .tt T4 template, I should be able to use the following declaration:
<## assembly name="$(SolutionDir)\..\..\Build\lib\HedgehogDevelopment.CodeGeneration.Extensions.dll" #>
From what I can see, the SolutionDir is not being transformed, and I get an error message (below)
Note: The HedgehogDevelopment.CodeGeneration.Extensions.dll cannot be added to the GAC or the Visual Studio assembly folder as the DLL needs to passed along with the project.
I don't know how the TDS code generation is executed, so I am asking here to see if someone has resolved something similar.
Error | 10 |The host threw an exception while trying to resolve the
assembly reference
'$(SolutionDir)......\Build\lib\HedgehogDevelopment.CodeGeneration.Extensions.dll'.
The transformation will not be run.
The following Exception was
thrown: System.IO.FileLoadException: The given assembly name or
codebase was invalid. (Exception from HRESULT: 0x80131047) at
System.Reflection.AssemblyName.nInit(RuntimeAssembly& assembly,
Boolean forIntrospection, Boolean raiseResolveEvent)
at
System.Reflection.AssemblyName..ctor(String assemblyName)
at
Microsoft.VisualStudio.TextTemplating.GlobalAssemblyCacheHelper.GetLocation(String
strongName) at
Microsoft.VisualStudio.TextTemplating.VSHost.TextTemplatingService.ResolveAssemblyReference(String
assemblyReference) at
Microsoft.VisualStudio.TextTemplating.Engine.ResolveAssemblyReferences(ITextTemplatingEngineHost
host, TemplateProcessingSession session)
Make sure you add HedgehogDevelopment.CodeGeneration.Extensions.dll to either the GAC or the Visual Studio Assemblies folder:
https://github.com/HedgehogDevelopment/tds-codegen/wiki/Using-Extension-Methods
Or use the full path to the assembly in your directive.
UPDATE:
As an update to this, the extension methods have now been moved into T4 files so you no longer need to deploy the DLL to the GAC or Visual Studio folder. You can find the updated files in the Github repo.