I've got external folder with resources (graphics, movies, etc) which is shared between a couple of projects. I'm able to link this resource folder in FlashBuilder (as described in http://livedocs.adobe.com/flex/3/html/help.html?content=projects_5.html#155069). After that all the pathes to embeds are relative to the project, and that's the behaviour I want.
This linked resource appears in .project file as follows:
<linkedResources>
<link>
<name>resources</name>
<type>2</type>
<locationURI>DOCUMENTS/Shared/resources</locationURI>
</link>
</linkedResources>
Note, that it isn't source folder and it is not included in compilerSourcePath tag.
The question is how can I specify resource linked folder in mxmlc command line arguments?
-source-path is not working here, relative pathes to embeds can not be resolved.
Seems like it's not possible and there's no such option. FlashBuilder somehow passes all the workaround to mxmlc java wrapper, therefore it knows where to search resources.
In my project I used another method to achieve proper sharing of resources:
Autobuild step, which copies images and extractes fla files to resource folder in each project form the source directory.
All css files I moved to shared source folder (e.g. Common/css/main.css) - they are under source control. I added link to it via -source-path option.
After that all relative pathes in css started to look like ../../resources/image.png in both projects.
Maybe someone will find my experience helpful.
Related
I want to get a path to the project directory in Qt and reference the other files of my project relative to it. I know this issue have been already discussed here
Get current working directory in a Qt application
and here
How to get current working directory path of a Qt application?
but the answer is still unknown. In case it's impossible to get such a path then what is the approach of navigation among files of the Qt project.
Based on your comment, you are trying to:
Access some images which are being used in my program. I could of course put them into build target directory, but it becomes uncomfortable to pass my code to others.
The approach to store resource files in the project source directory and rely on such structure at runtime is not a greatest idea. I can't imagine the situation when mixing the concepts of initially decoupled source and build directories could be useful, correct me if I'm wrong.
So, according to your needs:
The most simple and plain way is to use the Qt resource system. The resource files are simply embedded into the executable, so there will be no need to access the file system.
Another way is the automatic deployment of the needed files. This answer describes the way to copy your files to the target directory using qmake.
I believe this question applies to CMSes in general.
I'm using a CMS, Kentico, for a particular web application. The CMS installer generates its own boilerplate project with 10,000+ files, and this project amounts to a runnable web app. Very few of the CMS-provided files are intended for modification. Yet standard practice is to add custom code to the project, and to check the entire project into source control.
I dislike the idea of checking in my entire CMS. I prefer my repository to contain only the code particular to the project, while vendor files are automatically "pulled in" from elsewhere. For example, Visual Studio can restore NuGet packages into a fixed location in the project, and this location can be ignored by version control.
In a way, development with the CMS is dirtier than when using a typical vendor library. Usually your own code depends on a library, while the library is independent from your code. However, the CMS wants to be your app, and your own code interweaves. The CMS requires customization of its own provided files. You can't just "pull in" the CMS files to a fixed location and then ignore that location.
Given this scenario, I'd still like to omit as many of the CMS files as possible. So far, I've settled on this strategy:
Keep a pristine, readonly copy of the CMS-provided files at a standard, local path.
Create a fresh project root directory.
Copy the CMS-provided project file to the project root.
In the copied project file, change the 10,000+ file paths to point to those pristine CMS files, which are external to the project root.
Place only files with custom code into the project root. If a CMS-provided file must be modified, copy it into the project root directory and use that copy.
This strategy sounds good in theory, but it's more complicated in practice. Here are a couple complications:
Changing 10,000+ file paths to "link" in external files turns out to be more than a find-replace operation. More complex mapping is necessary to preserve the pristine project's directory structure.
The web server requires all the files to be in the same directory. Using the project file to link in external files is fine for compilation, but you've split your web root in two.
For the latter problem, it seems the best workaround is to perform post-build copy operations. This is, in itself, more complex than it seems from the outset.
As I write this, I'm starting to feel like I should go ahead and just dump the entire working CMS into my repository. It feels dirty, but it's a hell of a lot simpler. Before I do that, does anyone have any experience or ideas for how I might accomplish my goal?
To restate my question: How can I exclude my CMS's provided files from my version control repository, while still including them both in my project / build script and in my web app root?
Here's another idea for how to accomplish this:
I establish a standard local directory for Kentico DLLs and the Kentico installer, which will not be in version control.
I create KenticoSupport.csproj, a class library of types extending built-in Kentico types, just as they are intended to be extended. This will also contain content, such as JS, CSS, ASPX, ASCX, etc. files. This will be in version control, but it references the central Kentico DLLs, which are not in version control.
I create KenticoBuilder.csproj, a mostly empty project that is mainly a build script. It also contains a few simple *.patch files to modify matching Kentico files, such as Web.config and Global.asax.cs. This is under version control.
Here's what the KenticoBuilder.csproj script does:
Build KenticoSupport.csproj.
Create an output directory that will serve as both a web root and a project directory.
Install / copy the pristine Kentico project files into the output directory.
Apply patches to matching Kentico files in the output directory (mainly to add config lines and custom bootstrapping).
Copy custom DLLs and content from KenticoSupport to matching locations in the output directory.
Build the project at the output directory.
It's complex, but I think it might just work. Thoughts, anyone?
Kentico should hopefully be fixing this soon, with pre-built dlls you can reference rather than rebuilding the entire CMS every time you modify C#.
Until then, have you considered using a Symbolic Links to reference your pristine files? Then just overriding the links with your modified files when need be?
See this other question if you haven't used them before. mklink comes with newer Windows versions (Command-line), but there are a bunch of third party GUI based apps as well.
I came up with an ideal strategy:
Place the pristine CMS files at an external "code libraries" location, and make them read-only for good measure.
Make a copy of the CMS-supplied project file.
Convert all project items to link to the code library's copy, including assembly references. The required link element for MSBuild complicates this, so I wrote a little console app to parse the XML and generate the necessary elements. I also store the path to the library in a property.
At this point, you have a compilable project. The files are all just links to read-only, baseline, CMS-provided files, but the IDE shows a nice directory structure, as if the files were actually in your repository. As you customize, you can replace the links with your own actual files.
However, your website files are now split between two completely different locations. The web server needs them to actually be in the same directory. This is where some scripting comes in handy.
Using your build scripting tool, plug into the post-build event to copy linked files into the project directory. Naturally, you can omit the compiled files. Here's how I did it with MSBuild (thanks to this blog post):
<Target Name="AfterBuild">
<ItemGroup>
<LinkedKenticoFiles Include="#(None);#(EmbeddedResource);#(Content)"
Condition="$([System.String]::new('%(FullPath)').StartsWith('$(MY_LIBRARY_BASE_PATH)'))" />
</ItemGroup>
<Copy SourceFiles="%(LinkedKenticoFiles.Identity)"
DestinationFiles="%(LinkedKenticoFiles.Link)"
SkipUnchangedFiles='true' />
</Target>
Optionally, plug into the cleaning event to remove those files. I used similar MSBuild syntax to delete the files, and because it leaves behind empty directories, I remove empty directories, too. (Thanks to this answer.)
<Target Name="BeforeClean">
<ItemGroup>
<LinkedKenticoFiles Include="#(None);#(EmbeddedResource);#(Content)"
Condition="$([System.String]::new('%(FullPath)').StartsWith('$(MY_LIBRARY_BASE_PATH)'))" />
</ItemGroup>
<Delete Files="%(LinkedKenticoFiles.Link)" />
<ItemGroup>
<Directories Include="$([System.IO.Directory]::GetDirectories($(MSBuildProjectDirectory), '*', System.IO.SearchOption.AllDirectories))" />
<Directories>
<Files>$([System.IO.Directory]::GetFiles("%(Directories.Identity)", "*", System.IO.SearchOption.AllDirectories).get_Length())</Files>
</Directories>
</ItemGroup>
<RemoveDir Directories="#(Directories)" Condition="%(Files)=='0'" />
</Target>
Optionally, make your source control ignore the site / project folder, to avoid checking in the temporary, copied site files.
I'm using QWebView to run a web app. There are 650+ files. Placing the web app's directory in the source directory does not result in the executable bundling the directory.
How do I include the entire web app directory so that the executable will be able to render the files.
Note: I have currently added index.html as a resource, and can access it with qrc:// - But since I cannot add the entire directory structure to a qrc (can I?), the executable does not include the other files.
You need to put an XML node into the .qrc file for each file you want to use using the Qt resource system.
This can be done using a simple pre-build script. Take a look at qrcgen. Quoting the blog post behind this link:
The script I created, qrcgen, takes a directory and a prefix, recursively scans the directory and generates a .qrc file with the same name as the directory scanned. It has solved my problem, and I hope it can help others. It is also available via PyPI, just "easy_install qrcgen".
In order to update the .qrc file whenever your directory contens change, you need to include this step into your build process:
For C++/Qt projects, you can add this step in the build configuration in QtCreator or add in your qmake file a system(...) statement. Note that such commands aren't portable in general. (If it's not portable, you can put some operating system conditions around multiple commands.)
For PyQt/PySide projects, I don't know how to do this, but I'm sure you find a solution for this too.
I'm using git to track a project I'm developing in Flash Builder, and I'm wondering the best way to go about having it track it, especially regarding Flash Builder generated files, Compiler generated files, and source files that aren't necessarily flex files.
I had it set up to ignore all of the flash builder .project & debugging directories via .gitignore:
.actionScriptProperties
.flexProperties
.metadata
.project
.settings
bin-debug
and also treating any swf/swc files as binaries via .gitattributes
*.swf -crlf -diff -merge
*.swc -crlf -diff -merge
One issue with this setup is checking out this project and using
it in Flash Builder from scratch:
Flash Builder doesn't like it when
you have a project folder without
the .project files. Only way to
import the source into Flash Builder is to:
Create a new Flex Application
Smother the template files it
created (specifially APP_NAME.mxml)
with a git clone.
Where do I put libraries? From a git perspective, I'd like to have them in the lib folder of the repo so when someone clones the repo, everything just works, but from a local file system perspective I'd like to store all my libraries in a single location and use Flash Builder to reference them, as I may update the library or download a later version. Maybe I should put the libraries in their own repo and load them as a git module? This way I don't need to manually remember to update my Y library files in all X projects that are using them, edit: they will simply update when I update each projects' submodules.
And what about external swfs/flex modules? I've was sticking external swf files in the bin-debug folder for now so the SWFLoader class can find them, but because I'm .gitignoring the bin-debug folder, they don't come with the repo when it's cloned.
One final issue is where to keep the files for the server. Do I have them in a separate repo? I'm using php VOs' with AMFPHP so it's good to be able to edit the php files alongside my actionscript files in Flash Builder... but they don't belong in the project src folder.
The current solution I'm using is:
Creating a 'server' folder in the project root
Pointing an apache virtualhost at it
Setting the run/debug settings to http://APP_NAME.localhost
Then using the server folder as a replacement for bin-debug when the files get exported
The problem with this is I've got a big mess of compiler generated files, and non-AS source files in my server folder. It just doesn't seem like an elegant solution.
How do you set up git to work with flash builder smoothly? Could all this be resolved with multiple git repos/Flash Builder projects, or an ANT script or something?
Thanks.
I've found a good solution which avoids all of the horror of having untracked files and keeping a massive .ignore list:
CLEAN your projects before you git commit.
Simple as that.
Whether it be by Flash Builder or by ant, you should have the ability to clean anyway, so if you simply clean before you commit, the problem of generated files is solved. Duh.
In fact you could probably set it up as a git hook or something.
Typically for eclipse projects with any SCM, I initially check in everything including .projects, etc., but maybe except bin-debug in your case. Then just make sure that anybody who checks out the project never checks back in those .xxx files. For instance, when I use perforce, I first check out the .xxx files to a changelist that I never check in. Then check out the rest to a separate changelist.
Another tip is to use user defined library variables when working with build paths, etc.
I noticed that Eclipse (Flex Builder) generates hundreds of metadata files. Should I check them into my source control? They seem necessary, because if I delete them Flex Builder just opens up an empty workbench...
Some of these files plainly do not belong in source control (like .history files and some cache files). If I delete them my project opens up again without a hitch. But the list is long and there seem to be no clear separation between folders that contain files that belong in source control and those that do not.
I can't just shove them all into svn, even if I were to ignore the inefficiency, because Eclipse generates new ones constantly, with different names, which in turn also seem to be crucial for the project to load.
Can someone please enlighten me?
Don't check in the hundreds of metadata files. If you want to be able to check out the project in a way that it can just be imported, then check in:
.actionScriptProperties
.project
.flexProperties
And "html-template" and "libs". As Christian says, any resources you depend on. I usually keep those as separate Flex Library projects though.
I generally put all of my source code under src, and I check in src and all of its descendents. If my project relies on any external dependencies (e.g., the Cairngorm SWC, as3corelib, etc.), Flash/graphical assets, stylesheets, or resource files, I check those in, too. But I don't check in any generated (bin-*), intermediate or IDE-specific stuff, because having that stuff in source control doesn't seem to provide much practical benefit, and in my experience has only caused me headaches; in general, I check in the most minimal set of whatever I'd need -- given a clean FlexBuilder installation (or none at all -- for example, if I were compiling instead with mxmlc or compc) and an empty project -- to build the project successfully.
Most of the eclipse project files, like .project, .properties, everything in .settings, can go into your source control. As long as the files don't have user-dependent settings like file paths or local urls, you should be fine.
One method we use is creating local property files that don't get used in SCM, but are included in the ones that do. I.E an ant build file including a local.properties file which has local metadata.
What if the .actionScriptProperties, .project, or .flexProperties have user-dependent stuff in them? Typically this will be url or path information. What's the best practice way of externalizing this? I tried creating path variables, but this only works obviously for paths. Not for things like hostname, etc.