I'm using Dojo 1.9, and am happily building layer files using the Dojo builder. What I'd like to be able to do is build my layer files containing my modules which refer to third party modules, but where I only have pre-built layer files containing those modules rather than the individual third party module files.
(There are two reasons for wanting this: sometimes I don't have the individual module files, just the layer files, and sometimes even if I do have the individual module files, I have no intention of bundling them into my layer, and so don't want to increase the build time by having the builder scan all of those module files.)
If I have the raw module-by-module source for those third party modules, I can make it all work fine, but can it be made to work if I only have the pre-built Dojo layer?
I've tried specifying 'exclude' options in my layer specification, but that seems to affect which modules are generated into my layer rather than which modules it tries to locate as individual module files.
Is there a way to do this?
A bit late, though hoping this may be of any help to someone. Facing the same absence of relevant answer, I eventually gave up trying to get it done with the builder, especially given that my 3rd party wouldn't build even by itself. Instead, I set up grunt-contrib-concat to output AMD layers, and built a project with it, while caring to explicitely reference the library layers within dojoConfig.
https://github.com/mdolidon/grunt-amd-concat
Related
In the past I have created a jar file that contained many "helper functions" that I used and made common to many different applications. I felt this was important as anytime I used my "helper" jar file in any new applications or when making changes to any existing ones, the latest and most up to date version of my "helper" jar was always used. It was developed separately and had it's own version control.
I'm looking to do something similar with C/C++
At the moment I have a collection of headers, doing something similar to my "helper" jar in java but finding it cumbersome managing changes, ensuring the most up to date collections are used. So for example, if I made some changes to these "helper" headers, I need to copy them into each project and rebuild.
If we take the below as an example of what I do in Java;
and the below is the structure that I'd like to do something similar with in C++;
I'd like some way of keeping my_includes separate so that any changes I made to my_includes are automatically included in any existing or new applications, in the way Utilities.jar is in the above Java example
I accept that I cant build a library or such as it won't then be as portable, right?
I suspect I'm missing something quite obvious, just not to me.
All helpful comments appreciated, thanks in advance...
At first you could create a library from your utilitis.cpp and all include files independently and add this library to any project. I just provide URL for sample generate the static and shared library.
Create static and shared library (GCC)
And then you can add custom include files to any project in c++ just need to add the specific directories to your include Path in compile time base your platform or if you use cmake you can edit the "include_directories". And also you should link the generated library to your project as described in provided URL.
I have an assets/CDN project which contains my own and third party libs like JQuery. My own scripts are written in TypeScript. All these files get referenced in about five different projects.
If I want to write some TypeScript in one of those five projects that references some TypeScript in the assets project I manually generate and copy across a declaration file.
What would be your recommendation for a better way to manage this process?
I'm using Grunt to run the TypeScript compiler. I can run it with the 'declarations' option but this won't let me put all the declarations in a separate folder ready to be 'collected' by the other projects.
I've looked at the TS Project and DTS Bundle but these don't seem very flexible and I'm worried I'll have to switch to something else later as TypeScript moves in another direction. Plus I'm not keen on the single file approach. But I'm not ruling them out entirely.
I wrote typings which has the express goal of solving definition files in TypeScript (https://github.com/typings/typings). It's hard to tell if it'll work with what you're asking though, since I don't know how you consume the other projects you have. If you want to be able to use dependencies and package it them in dependencies of your other projects, all without having to make a single "declaration" generation step and no conflicts, it might be worth trying it out.
The only overhead of it right now is having to convert DefinitelyTyped into external module declarations, since they're incompatible.
Heads up, this is going to be confusing:
I customized 9 files from Qt5.2: qquicktextdocument.cpp qquicktextdocument.h qquicktextedit.cpp qquicktextedit_p.h qquicktextedit_p_p.h qquicktextnode.cpp qquicktextnodeengine.cpp qquicktextnodeengine_p.h qquicktextnode_p.h
Each file is simply prefixed with a letter and still inside /qtdeclarative/src/quick/items/. I am 100% happy with the modifications I made being put under GPL etc. I somewhat want my end application (discussed below) to be Apache or MIT, but, I'm flexible.
My modifications work fine. When I modify a few additional files I am able to compile them along with the rest of Qt (at the same time, using the same make command). But these modifications are going into another Qt application that I am making which I want other people to be able to use, and requiring general consumers to have a custom compiled version of Qt would be obviously absurd.
I want to package/compile/do something, that will enable me to include the modifications in my final project as a shared library, or something.
As a web developer writing C++ and Qt, I am very confused about linking shared libraries, header files, etc.
To recap, I modified Qt 5.2 and made a custom compilation of it for an application I am building, and I want people to be able to run that application without having to have a custom compilation of Qt. I need a way to decouple my Qt modifications from Qt.
I realize this might be a big topic, I'm not expecting a step by step guide, just some general guidance. So far I have tried compiling my modified files as a library, then including that library in my actual project, but I am getting undefined references and missing files all over the place. (I don't know if I did anything right)
I am also currently looking at subclassing the classes I want but I'm unsure about this. It might require copy pasting some code, which could have licensing issues?
end goal: be able to have a wavy underline (in qml) for incorrectly spelt words.
Thank You.
My 5 cents.
If your changes can be useful (in general) to other people you can try to push them to upstream via codereview.
If you want your application to run only in windows everything become obvious: in windows it is normal to provide your application with shared libraries (to avoid DLL HELL). Btw, have you heard about static linking?
Qt has some plugin mechanism. You can compile your code into shared object (dynamic library) and install it with your application. For example, QML FolderListModel do this. You can look at code in $qt5_src/qtdeclarative/src/imports/folderlistmodel.
I've got a few open source applications. These depend on a few third party components, notably Crypto++ and Boost. There are a couple of options to take:
Put third party code into version control, and include it with distributions of my code. On one hand, this is the easiest for people to use because they can compile directly out of my source control repository. On the other, they might be wasting bandwidth downloading source they already have, or end up having to fight with my library in order to remove the third party bits. Furthermore, source control tools often have trouble dealing with massive libraries like Boost.
Don't include third party code at all. This forces people to go out of their way to be able to use my library. On the other hand it means my source control repository and distributions will be small.
Something I have not yet anticipated.
What should I do?
Note: I'm not working in an environment where reliance on a dependency mapper like aptitude, apt-get, or yum are acceptable.
Option 3: Don't include it in your code distribution but instead include a (link to a) download, which should match the most recent version you support.
Also, explicitly list your dependencies and the most recent versions you support.
This allows users to do however they want. Want your code with dependencies? Load both from one source. Want only part of the dependencies because you have the others? Load part of them. Want only your code? Load it seperately.
Option 4: Offer 2 versions, one including the dependencies and the other without but combined with option 3 above.
I suggest Autoconf which was designed to abstract these worries away from you.
I doubt you can be expected to maintain build scripts for all of your dependencies across all platforms. Another problem with keeping 3rd party code in your svn is that now you also need to track down their dependencies and so on.
I think its a good idea to have dependencies in the SVN. That way developers can simply check-out and compile. Also you avoid the problem with different incompatible versions of your dependencies.
If you put the dependencies in a separate folder then developers can choose not to check-out your dependencies if they alrdy have them...
If you have a good package manager, than I would definitely not include dependencies in your repository. If you list the dependencies, it should be pretty easy for someone compiling it to get them from the repos.
If you wanted to, you could include all of the dependencies as an additional download if you wanted to. But mixing them in with the code your working is generally not a good idea.
There are already some questions about dependency managers here, but it seems to me that they are mostly about build systems, while I am looking for something targeted purely at making dependency tracking and resolution simpler (and I'm not necessarily interested in learning a new build system).
So, typically we have a project and some common code with another project. This common code is organized as a library, so when I want to get the latest code version for a project, I should also go get all the libraries from the source control. To do this, I need a list of dependencies. Then, to build the project I can reuse this list too.
I've looked at Maven and Ivy, but I'm not sure if they would be appropriate for C++, as they look quite heavily java-targeted (even though there might be plugins for C++, I haven't found people recommending them).
I see it as a GUI tool producing some standardized dependency list which can then be parsed by different scripts etc. It would be nice if it could integrate with source control (tag, get a tagged version with dependencies etc), but that's optional.
Would you have any suggestions? Maybe I'm just missing something, and usually it's done some other way with no need for such a tool? Thanks.
You can use Maven in relationship with C++ in two ways. First you can use it for dependency management of components between each other. Second you can use Maven-nar-plugin for creating shared libraries and unit tests in relationship with boost library (my experience). In the end you can create RPM's (maven-rpm-plugin) out of it to have adequate installation medium. Furthermore i have created the installation for CI environment via Maven (RPM's for Hudson, Nexus installation in RPM's).
I'm not sure if you would see an version control system (VCS) as build tool but Mercurial and Git support sub-repositories. In your case a sub-repository would be your dependencies:
Join multiple subrepos into one and preserve history in Mercurial
Multiple git repo in one project
Use your VCS to archive the build results -- needed anyway for maintenance -- and refer to the libs and header files in your build environment.
If you are looking for a reference take a look at https://android.googlesource.com/platform/manifest.