I have an external project that unzips a bunch of header files to ${EXTERNAL_INSTALL_PATH}/extproj.
The problem is that I have no way of telling my various executable to build extproj beforehand unless I do add_dependencies(myapp extproj).
I have a lot of executables though, so that's a lot of add_dependencies!
Is there a way to just do something like:
add_dependencies(header_file.h extproj) such that any app that #include <header_file.h> automatically knows to build extproj?
Related
I have created a Razor Class Library to be able to distribute some global styles and views across projects, but I can't seem to import my .less files from the Razor Class Library.
In my RCL I have:
Styles
-Shared
-layout.less
-variables.less
In the project referencing the RCL I have:
Styles
-main.less
main.less only has:
#import "./Shared/variables.less";
When I run a build via webpack I get errors that it cannot resolve ./Shared/variables.less, but it works fine if I copy the Shared directory from the RCL into the project referencing it.
I have the BuildAction for the RCL .less files set to Content, is there anything I am missing, or is this something that is not possible?
It's some what possible, but not for specifically what you're trying to do here. An RCL is ultimately a DLL, so the only thing you can include in it, is things that can be "compiled" into that. I say compiled with quotes, because static files can be included as embedded resources, so while they're not themselves compiled, they are still literally being embedded into the resulting DLL. With the ManifestEmbeddedFileProvider, the app using your RCL can read from these embedded resources as if they were literally on the filesystem.
However, and importantly, they are not on the the filesystem, which means using things like webpack is a 100% no-go. What you'll need to do is actually do a webpack build as part of the RCL, and then embed the resulting static resources in the RCL. Your app, then, can have its own webpack build for it's own resources, but you won't be able to combine primitives from the RCL with primitives from your app.
You could possibly manually manage the build order and run a powershell script post build (making sure that the correct dll is building first) and interrogate the dll and extract the required files (?) into the correct folders in wwwroot, or wherever, before the webpack build. I think that happens after the projects are built, but I'm not an expert on webpack either and I haven't actually tried this.
Also technically if you want any static or view files to be embedded in the dll you would select "Embedded resource", well that is how I've done it in the past.
I'm having a problem getting the 'System Header Search Paths' in build settings to work in Xcode and allow me to use #import <Core/CoreBlocks.h> rather than a local copy and #import "CoreBlocks.h"
First I need to "frame" the problem.
I have built a framework that I use across many if not all my projects. This is Core.framework . Inside the framework is the requisite "Headers" directory and within that 40 other headers, all of which are included in the 41'st header Core.h
I drop the Core.framework into another project and the other project headers or source files then import:
#import <Core/Core.h>
and get all the functionality of the 40 modules in the framework. Works fine.
BUT, what I need is a simple way to run the 40 modules of Core.framework outside the framework construct, as a separate build or project, with just the source and breakpoints, so I can debug and enhance it.
I try to define the framework's source directory as a search path for the other project:
yet the compiler complains about the inability to find the headers in the source code:
is all I get for all of the imports even though they all reside in the lower Core directory below that path:
~/Development/Projects/Core/Core/Core/NSRange+Core.h
And that's where I'm at a loss. What am I doing wrong?
Found out why... Xcode for some reason can't use the *nix home directory notation in a pathname.
In other words while:
~/Development/Projects/Core/Core
does not work, the expanded equivalent:
/Users/BC/Development/Projects/Core/Core
does work in the Xcode system header search paths, yet it is not obvious as to why...
I want to set up my HelloWorld intellij-erlang project with all files in the same directory so I can easily switch between IDEA and emacs/vim.
<my-project>/hello.erl
<my-project>/hello.beam
Now, if I configure the output directory to be the same as the source, hello.erl gets emptied as part of the build and the compilation fails.
I assumed it's something to do with copying resources to the output directory, so I've configured intellij-erlang to exclude *.erl from the resources with a !?*.erl pattern, but this does not have any effect, hello.erl still gets emptied before the compilation takes place.
As an experiment, I've also tried using separate src and out directories, and intellij-erlang always copies the *.erl to out irrespective of the resource patterns.
Based on all this, I would conclude that intellij-erlang cannot work with all files in the same directory. Have I missed anything?
Erlang programs should be build on standard OTP directory structure. Build tools like rebar (used by intellij) or erlang.mk build on this conventions. And so should all IDE's.
Intellij does it, just like you notice. And so does Emacs's plugin (that I use and can confirm). I would guess so does Vim's one.
So if you would like to be able to switch easily between your IDE's you should try to keep to this convetion of keeping you source files in src and compiled files in bin (and headers in include).
I have written a CMake module that contains a couple of useful macros that I would like to use across a number of other CMake projects. However, I'm not sure where to put the module.
I would like to be able to do this inside each project that uses the macro:
include(MyModule)
However, I'm not sure if there is an easy and cross-platform way of achieving this. In fact, I can't even get it to work on Unix. I put the module (MyModule.cmake) in the following locations:
/usr/lib/cmake/
/usr/lib/cmake/Modules
/usr/local/lib/cmake
/usr/local/lib/cmake/Modules
...and the project with the include() was unable to load the module.
What is the correct location for this module? Is there a better approach?
I should also point out that the macros are not related to "finding" a third-party library and therefore have nothing to do with find_package().
Put the module in a directory of your choice, and then add that directory to CMAKE_MODULE_PATH using list(APPEND).
You can even host that module somewhere and then download it via file(DOWNLOAD). If you download it to the same directory as the current CMake script being processed, you just include(MyModule.cmake) and don't need to modify CMAKE_MODULE_PATH.
You could download the file to a common location on disk and then add a check using if(EXISTS "${module_location_on_disk}") to skip the download if it's already downloaded. Of course, more logic will be required if your module changes, or you want to have a common location and multiple versions of the module, but that's out of those scope of your question.
I started using sass scss stylesheets. These generate *.css files from *.scss files. My question is, which files do you check into version control? Right now I check in both main.scss and the generated main.css. I wonder though if there is a way to just check in the *.scss file and to ensure that the *.css files get generated on deployment.
I prefer to check them in. We deploy to our staging and production environments from git and I prefer not to rely on yet another tool/compilation when deploying to production. This way, its absolutely clear what is being pushed out.
In general, you usually don't need to check generated files into source control. As long as your code generation works consistently, and you use it consistently to update your target .css files, I don't think you would need to put them in source control.
That said, the suggestion to not put generated files into source control is usually intended more for binary files (i.e. libs or executables generated from a build). The main reason for this is that binary files cannot be easily diffed/merged, so if multiple people try to checkin changes to the same binary, you may end up with merging issues that cannot be easily resolved. Since you're dealing with plain text css files, I don't think it's that big of a deal to just put them in source control too, just so you have a backup of the actual target file.
I like to borrow from the conventions used by server side developers when handling compiled front-end code like sass. I keep all of my source separate from compiled code. Here's how I set it up:
Put your source in a src directory, under main/language-name, in this case:
/path-to-my-app/src/main/sass/my-syntactically-awesome-file.scss
Then put tests in an identical test directory (you shouldn't need any tests for sass, though:
/path-to-my-app/src/test/sass/my-syntactically-awesome-test.whatever
Then put your compiled code in a publish-ready directory, like so:
/path-to-my-app/publish/css/my-syntactically-awesome-file.css
Then commit the whole shebang (!)
You can make sure you are always putting your css in the right place like so:
$ cd /path-to-my-app
$ sass --watch src/main/sass/*.scss:publish/css/
Now you're a mother effing programmer, baby!