I need to be able to tune a construction environment so that I can either build a static or a shared objects in lower levels. Currently, I came up with the following approach:
top-level SConstruct:
if build_shared:
env.Replace(ObjectBuilder = env.SharedObject)
env.Replace(LibraryBuilder = env.SharedLibrary)
else:
env.Replace(ObjectBuilder = env.StaticObject)
env.Replace(LibraryBuilder = env.StaticLibrary)
and in lower-level SConstructs I invoke them by name:
env['ObjectBuilder']('foo.c')
env['LibraryBuilder']('lib', objects)
However, I'm not sure how sound this solution is. Is there a more straightforward/proper way to achieve the same functionality?
Thanks in advance.
The easiest way is to declare your own wrapper for env.Library() that simply passes its parameters to either env.StaticLibrary() or env.SharedLibrary().
Depending on whatever construction variable/scons option, you can have that wrapper alternate between the two.
def MyLibraryWrapper(self, *args, **kwargs):
if self['BUILD_SHARED']:
return self.SharedLibrary(*args, **kwargs)
else:
return self.StaticLibrary(*args, **kwargs)
env.SetDefault(BUILD_SHARED = False)
env.AddMethod(MyLibraryWrapper)
Make sure that snippet is your SConstruct, before any SConscript is parsed. To make it extra clean, create a tool in site_scons/site_tools and load it using env.Tool().
If this is a user controllable option, you may want to use the AddOption, GetOption interfaces to control whether static or dynamic libraries are built. IMHO, that methodology doesn't seem too bad, but I've not seen many SCons scripts aside from my own.
Related
Is there a way to disable react-jsx transformation in some files of a ReasonReact project?
I think the other way around is possible by not adding "reason": { "react-jsx": 3 } to bsconfig.json and by adding ##bs.config({jsx: 3}) to the top of the files where you want react-jsx transformation, but that would force me to add this annotation in too many files.
I'd like to build a small DSL based on JSX in a few files while benefiting from React in the rest of my project.
Note: the solution suggested is not very straight forward, and I think it's much simpler to add ##bs.config annotations explicitly in all required files, but if you really don't want to do that, the following might work.
If I'm reading the compiler code correctly, user-defined ppxs are applied before ReasonReact ppx. In the linked compiler module, Cmd_ppx_apply.apply_rewriters will apply with all arguments passed with -ppx flag, and Ppx_entry.rewrite_implementation is ReasonReact ppx.
Assuming that's true, one could have a ppx that checks a top-level statement like ##custom.jsx at the top of the file, that the ppx would check. The ReasonReact ppx used to have a similar check, in case it serves as reference.
Then if this statement is found, the custom ppx would process the nodes that have the #JSX attributes and make sure it removes the attributes from them, so when the compiler passes the AST to ReasonReact ppx, it won't see them.
Note this would break if the ReScript ppx pipeline is updated one day to a driver-based one (unlikely I'd say because that would mean ReScript should support native libraries as 1st class citizens somehow), or if the ordering that was mentioned above changes (ReasonReact ppx applies before user-defined ones).
Currently, I am working on a project to transpile from my company's in house scripting language, which is Object Orientated and takes quite a few features from other languages, into Groovy, which has many similar features.
To keep code as close to original as possible, I am trying to leave certain function names and parameters the same. To cater for this, I would like to write a set of libraries that can be imported.
For example, say I have an inbuilt method in the original scripting language,
I would like to be able to write the definition for this method in a groovy file, that can then be imported when needed, and the method may be called.
Tools.groovy
// filename: Tools.groovy
public String foo(String bar) {
return bar;
}
and in another file
Main.groovy
// filename: Main.groovy
import Tools;
String bat = foo("bar")
I know you can can compile class files into jars and put them into the class path, but a lot of the methods I will need to implement will either require meta programming or won't be associated with an object.
Sorry if it's either a bad question or not clear enough. I'm not sure whether its even possible.
Cheers
I believe you should be able to create libraries and reuse them when needed.
All you need to do is create class and add the static methods if you do not have to create instances, non static methods otherwise. Then it looks like you already aware how to proceed later.
For instance, you can create utilities classes for String, List, etc based on your description.
By the way, even if you do not create libraries, it is even possible to write one lines in groovy achieve what you may needed most of the cases.
I've been tasked with creating conformance tests of user input, the task if fairly tricky and we need very high levels of reliability. The server runs on PHP, the client runs on JS, and I thought Haxe might reduce duplicative work.
However, I'm having trouble with deadcode removal. Since I am just creating helper functions (utilObject.isMeaningOfLife(42)) I don't have a main program that calls each one. I tried adding #:keep: to a utility class, but it was cut out anyway.
I tried to specify that utility class through the -main switch, but I had to add a dummy main() method and this doesn't scale beyond that single class.
You can force the inclusion of all the files defined in a given package and its sub packages to be included in the build using a compiler argument.
haxe --macro include('my.package') ..etc
This is a shortcut to the macro.Compiler.include function.
As you can see the signature of this function allows you to do it recursive and also exclude packages.
static include (pack:String, rec:Bool = true, ?ignore:Array<String>, ?classPaths:Array<String>):Void
I think you don't have to use #:keep in that case for each library class.
I'm not sure if this is what you are looking for, I hope it helps.
Otherwise this could be helpful checks:
Is it bad that the code is cut away if you don't use it?
It could also be the case some code is inlined in the final output?
Compile your code using the compiler flag -dce std as mentioned in comments.
If you use the static analyzer, don't use it.
Add #:keep and reference the class+function somewhere.
Otherwise provide minimal setup if you can reproduce.
I know that since Groovy 2.0 there are annotations for static compilation.
However it's ease to omit such annotation by accident and still run into troubles.
Is there any way to achieve the opposite compiler behaviour, like compile static all project files by default and compile dynamic only files chosen by purpose with some kind #CompileDynamic annotation for example?
I have found some (I believe recently introduced) feature which allows doing so with Gradle.
In build.gradle file for the project containing groovy sources we need to add following lines:
compileGroovy {
configure(groovyOptions) {
configurationScript = file("$rootDir/config/groovy/compiler-config.groovy")
}
}
or compileTestGroovy { ... for applying the same to test sources. Keep in mind that neither static compilation nor type checking works well with Spock Framework though. Spock by its nature utilizes dynamic 'groovyness' a lot.
Then on a root of the project create folder config/groovy/ and a file named compiler-config.groovy within. The content of the file is as follows:
import groovy.transform.CompileStatic
withConfig(configuration) {
ast(CompileStatic)
}
Obviously path and name of the configurationScript may vary and it's up to you. It shouldn't rather go to the same src/main/groovy though as it would be mixing totally separate concerns.
The same may be done with groovy.transform.TypeChecked or any other annotation, of course.
To reverse applied behaviour on certain classes or methods then #CompileDynamic annotation or #TypeChecked(TypeCheckingMode.SKIP) respectively may be used.
I'm not sure how to achieve the same when no Gradle is in use as build tool. I may update this answer in the future with such info though.
Not at this time, but there is an open Jira issue here you can follow to watch progress for this feature
There was also a discussion about methods for doing this on the Groovy developers list
In scons, I am attempting to make a UnitTest system (see code below), based on the great example from here: http://spacepants.org/blog/scons-unit-test
However due to a problem in recent scons 2.0.1 and newer, this cases a dependency cycle, as documented here: http://old.nabble.com/AddPostAction-executes-on-first-build-but-not-subsequent-td18360675.html (and elsewhere).
Does anyone know of a good work-around or replacement solution to this problem?
Code:
def UnitTest(env, target, source, **kwargs):
curTest = env.Program(target, source, **kwargs)
env.AddPostAction(curTest, curTest[0].abspath)
env.Alias('unit_tests', curTest)
env.AlwaysBuild(curTest)
return curTest
SConsEnvironment.UnitTest = UnitTest
mandolineTest = env.UnitTest(target='./codeTest',
source = mix(['test.cc', 'base.cc'),
LIBS = default_libs + ['bgl',],
LIBPATH = default_libs_path,
CPPPATH = default_includes )
I found a workaround for this problem. By using:
env.AddPostAction(curTest, curTest[0].abspath)
it appears that SCons tries to be clever and add a build dependency for curTest[0].abspath to itself, causing this circular dependency problem. The solution is to "hide" the execution of the command from SCons so it can't figure out what you are doing:
env.AddPostAction(curTest, lambda *_, **__: os.system(curTest[0].abspath))
For my unit test system (which is slightly different from yours but had the same problem), this has the desired effect of running the unit test whenever any of its dependencies changes, and not running it if nothing relevant has changed.