New to go. I'm familiar with the ability to consume build tags in source files like so:
// +build linux arm,!linux
but is there any way to create/export build tags in a source file? Something like:
// +build +custom_tag_name
I'm trying to do what the -tags argument does inside of a source file instead of adding it to a makefile so that when a library is added to a project, it will "set" certain tags that can be used in other files.
You can't do that. Source files can only set build constraints on themselves, they can't satisfy constraints. Constraints can only be satisfied as noted - implicitly by the environment, or explicitly via the -tags flag. Build constraints are a way to achieve environment-sensitive conditional compilation. Using one source file to control the build of another doesn't really make sense; you know at build time whether file A is in the build, so you know whether file B should be in the build. This seems like an XY Problem, possibly better solved by a mechanism similar to that of the SQL drivers (registering a handler in an init function) or something like that?
Related
I am rewriting in Go a home-grade program of mine that was previously in Python, learning on the way. As I reconsider whole sections of the code, it would be great if I could ignore some .go files I wrote (they throw compilation errors which is OK as they are not synchronized with my latest approach to the problem).
I could move them out of the directory, or rename them but I was wondering whether there would be a more idiomatic way to ignore some .go files in a module directory?
Build tags fit perfectly to your use case.
A Build Constraint or also known as Build Tag is used to include or exclude files in a package during a build process. With this, we can build different types of builds from the same source code.
So if you want to exclude a file from the build process, give it a different Build Tag. For example if you use //go:build exclude at the top of the file when you perform go build it won't be included. Note that exclude can be any word.
For more details on the Build Tags check out the following article by Dave Cheney here
TLDR
Add
//go:build exclude for go v1.17 and above
// +build exclude
at the top of the file you wish to ignore.
I have five RT targets that run almost equal code. I don't want to copy the VIs around to every target. Obviously because I don't want to recopy everything when changes happen. My prefered way would be that I write one VI with some conditional disable or case structures where the desicion whether it's enabled or not should be made with a build file/script.
To achive the case switching I'd like to define string constants in a build script and the dead code elemination should remove the unused cases after compilation.
What are the right tools to achive that? And how would you combine that with CI?
There's no API today to do this from the build, but I would suggest that a conditional disable structure is what you want. There are some ideas on the LV idea exchange requesting this functionality.
Some options:
I believe you can set the condition value per-target, so you can have one target for each build and set a different value for each target. Or you could have multiple projects and have a different value for each project.
The CDS should have a target condition. I'm not sure how detailed you can make that condition, because I rarely work with targets.
While there's no proper API, you can call a pre-build VI and set the condition's value in the project/target programmatically using a tag. Haven't done this myself, but there are examples here and here.
I'm not sure how this would work with CI, as I don't do automated builds. I'm guessing once it's part of the build spec, it will simply be executed when you call the build spec.
I have a source tree that can build two different projects from the same source. You call make A or make B, and the code is affected by ifdefs and similar using preprocessor variables to make two versions of the output. I'm looking to make dpkgs for these, and can make one fine, but am unsure of a good way to do this.
Currently I run dpkg-buildpackage, and I get A.deb or similar. Is there a way to do dpkg-buildpackage -target B so that it would then build a debian package for that project?
Things such as Creating multiple packages with dpkg-buildpackage seem to refer to having separate source code for the separate projects, which is not the case here.
I am in control of the source code so can make changes there.
Thanks.
You can set up one rules file to build two separate Debian packages at the same time. But if they are unrelated, this is an abuse of the Debian packaging procedure. It's designed for building multiple related Debian binary packages from a single source.
I have a project whose make process generates different build artifacts for each configuration, e.g. if initiated with make a=a0 b=b0 it would build object files into builds/a0.b0, generate a binary myproject.a0.b0, and finally update an ambiguous executable link to point to the most recently built project ln -s myproject.a0.b0 myproject. For this project, this is a useful feature mainly because:
It separates the object files for different configurations (so when I rebuild in another configuration I don't have to recompile every single source with new defines and configurations set, (unfortunately) a very common procedure).
It retains the binaries for each configuration (so it's not required to rebuild to use a different configuration if it has already been built).
It makes a copy (or link) to the last built binary which is useful in testing.
Right now this is implemented in an ugly decades-old non-portable Makefile. I'd like to reproduce the same behavior in CMake to allow easier building on other platforms but I have not been able to reproduce it in any reasonable manner. It seems like adding targets with add_library/executable, but doing this for each possible permutation of input parameters seems wrong. And I'm not sure I could get the utilization correct, allowing make, make a=a0, make b=b0 a=a0 as opposed to what specifying a cmake target would require: make myproject-a0.b0.
Is this possible to do in cmake? Namely:
Specify the build directory based on input parameters.
Accept the parameters as make arguments which can be left out (defaulted) to select the appropriate target at the level of the makefile (so it's not required to rerun cmake for a new configuration).
I'm currently trying to make splint available as an external tool in Visual Studio 2010.
It has problems with finding all includes for the file, since it seems that the INCLUDE variable is only set at build time and I haven't found any other possibility to extract the include files in any way.
My question: Would there be any way to extract the IncludeDir field from the current file's project's Properties page, ideally with the VC++'s AdditionalIncludeDirectories?
Note also that AdditionalIncludeDirectories is per file, as it can be changed for individual source files as well as on the project level, and if it contains macros it can evaluate differently for each source file too!
I'm not familiar with driving the MSBuild objects via the API, but that's used by the IDE. Whether that way or by simply running MSBuild.exe, you need to get it to figure out all the properties, conditions, etc. and then tell you the result. If everything is well behaved, you could create a target that also uses the ClCompile item array and emits the %(AdditionalIncludeDirectories) metadata somehow such as writing it to a file or passing it to your other tool somehow. That's what's used to generate the /I parameters to CL, and you can get the same values.
If things are not well behaved in that necessary values are changed during the detailed build process, you would need to get the same prelims done just like the ClCompile target normally does, too. Or just override ClCompile with your own (last definition of a target is used) so it certainly is in the same context.
Either way, there are places where build script files can be automatically included into all projects, so you can add your stuff there or use a command argument (I think) to MSBuild to add another Include.
—John