Due to quota restrictions I really need to build a project that I'm working on with all of the temporary files and build products in a separate directory (in my case /tmp/somewhere).
I'm used to doing this with CMake, is it possible with bjam, if so, how?
Yes you can. In your project declaration you can specify the build-dir location to anything you like instead of the default local bin.v2 location (see projects).
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'm trying to learn/use the Enterprise Library 5.0 Configuration tool and it seems like it would work perfectly with a few minor exceptions. The problem I am currently having is when it comes to working with different environments. We have 3 environments for one of our web sites, so I can create the 3 different environments within the configuration tool and I can set up the delta files and which properties to overwrite and when.
All is well until I Export Merged Environment Configuration File. When I do this, it creates the file as intended, however it changes the Environment Configuration File field to now include the absolute path.
Also, the delta file now contains a reference to the absolute path.
We use source control (VSTS) - so absolute paths are no good. Our build process consists of creating branches and then merging the code back into a root. We can't have absolute paths when the branches are created by different team members having their code in a different local folder structure.
Is there any way to stop the absolute path from automatically being added? Or any other suggestions?
My research indicates that there does not seem to be a way to make the GUI tool not override the Environment Configuration File value. The solution I am going with is to use the command line tool provided when installing the Enterprise Library. The command line tool is MergeConfiguration.exe.
I've just started using Subversion with ASP.NET web applications via the VisualSVN IDE plugin. There are a bunch of files which Visual Studio automatically generates so I don't want to version control these since they're not really part of the codebase and not required to build.
Does anyone have a definitive list of the main files that should be ignored when commiting to Subversion from an ASP.NET Web Application? and how would I go about ignoring these files. If possible I'd like to set it globally so that I don't have to keep doing the same thing for every ASP.NET Web Application that I write and create a new repository for.
Answers
A list of files to ignore as submitted in the answers below,
bin
obj
*.exe
*.pdb
*.suo
_ReSharper.*
*.user
General concensus seems to be that these should be ignored on a per project basis at the creation of the repository. They will then be ignored by all users using the repository.
Not really 'definitive', but I always ignore .suo and .user files and the bin/ and obj/ directories
Here's my ignore list from TortoiseSVN. VisualSVN requires TortoiseSVN and uses its settings.
bin obj *.exe *.pdb *.suo _ReSharper.* *.user
I haven't committed any unwanted (or not committed any wanted) files with this setting.
If you have any WCF service references then you only need to include the files Reference.cs and Reference.svcmap for each service reference.
The AnkhSVN plugin for Visual Studio has a list of files to ignore automatically and will only commits the files needed.
At least that's how I find it. It's taken me a few attempts at setting up the repository correctly but with AnkhSVN only commits a subset of he files that TortoiseSVn wants to commit. If ignores files recompiled on every Build for example.
Depending on your situation, you might want to keep the Web.config out of revision control as well. Different developers might require different configuration files for a website.
I'd recommend setting up a separate directory in your repository with a reference configuration file for the website and ignoring *.config on the actual project directory.
Additionally, to cover case sensitivity issues with "bin", I had to add [Bb]in to mine. So I have:
[Bb]in obj *.exe *.pdb *.suo _ReSharper.* *.user
Also, this link explains how to handle project specific excludes as well so that others get the same exclusion behavior only for the same project when they check it out:
http://svnbook.red-bean.com/en/1.1/ch07s02.html
I used the svn:ignore property on a particular directory to exclude a certain set of files that were copied into there (but I still wanted the directory itself in svn).
Use VisualSVN to do the initial "Add files to repository" and it automagically ignores the stuff you don't want-such as suo files and the bin/obj folders.
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.
As part of improvements to our build process, we are currently debating whether we should have separate project/solution files on our CI production environment from our local development environments.
The reason this has come about is because of reference problems we experienced in our previous project. On a frequent basis people would mistakenly add a reference to an assembly in the wrong location, which would mean it would work okay on their local environment, but might break on someone else's or on the build machine.
Also, the reference paths are in the csproj.user files which means these must be committed to source control, so everyone has to share these same settings.
So we are thinking about having separate projects and solutions on our CI server, so that when we do a build it uses these projects rather than local development ones.
It has obvious drawbacks such as an overhead to maintaining these separate files and the associated process that would need to be defined and followed, but it has benefits in that we would be in more control over EXACTLY what happens in the production environment.
What I haven't been able to find is anything on this subject - can't believe we are the only people to think about this - so all thoughts are welcome.
I know it's anachronistic. But the single best way I've found to handle the references issue is to have a folder mapped to a drive letter such as R: and then all projects build into or copy output into that folder also. Then all references are R:\SomeFile.dll etc. This gets you around the problem that sometimes references are added by absolute path and sometimes they are added relatively. (there's something to do with "HintPath" which I can't really remember)
The nice thing then, is that you can still use the same solution files on your build server. Which to be honest is an absolute must as you lose the certainty that what is being built on the dev machine is the same as on the build server otherwise.
In our largest project (a system comprising of many applications) we have the following structure
/3rdPartyAssemblies /App1 /App2 /App3 /.....
All external assemblies are added to 3rdPartyAssemblies/Vendor/Version/...
We have a CoreBuild.sln file which acts as an MSBuild script for all of the assemblies that are shared to ensure building in dependancy order (ie, make sure App1.Interfaces is built before App2 as App2 has a reference to App1.Interfaces).
All inter-application references target the /bin folder (we don't use bin/debug and bin/release, just bin, this way the references remain the same and we just change the release configuration depending on the build target).
Cruise Control builds the core solution for any dependencies before building any other app, and because the 3rdPartAssemblies folder is present on the server we ensure developer machines and build server have the same development layout.
Usually, you would be creating Build projects/scripts in some form or another for your Production, and so putting together another Solution file doesn't come in the picture.
It would be easier to train everyone to use project references, and create a directory under the project file structure for external assembly references. This way everyone follows the same environment.
We have changed our project structure (making use of SVN Externals) where each project is now completely self-contained. That is, any references never go outwith the project directory (for example, if Project A references ASM X, then ASM X exists within a subfolder of ProjectA)
I suspect that this should go some way towards helping solve some of our problems, but I can still see some advantages of having more control over the build projects.
#David - believe it or not this is what we actually have just now, and yet it's still causing us problems!
We're making some changes though, which are forced upon us due to moving to TeamCity and multiple build agents - so we can't have references to directories outwith the current project, as I've mentioned in my previous answer.
Look at the Externals section of this link to see what I mean - http://www.dummzeuch.de/delphi/subversion/english.html
I would strongly recommend against this.
Reference paths aren't only stored in the .user file. A hint path is stored in the project file itself. You should never have to check a .user file into source control.
Let there be one set of (okay, possibly versioned) solution/project files which all developers use, and the Release configurations of which are what you're ultimately building in production. Having separate project files is going to cause confusion down the road, when some project setting is tweaked, not carried across, and slipped into production.
You might also check this out:
http://www.objectsharp.com/cs/blogs/barry/archive/2004/10/29/988.aspx
http://bytes.com/forum/thread268546.html