I'm putting together a Qt5.1 build for our team to use for our project. I was able to build 32 and 64 bit binaries with debug symbols using the instructions here.
I built using VS2012.
After finishing the build I copied the bin, lib and include folders to our resources folder and all was well. However, a couple weeks later I moved the folder I had built from, and my application stopped running giving me the error.
I thought this was odd so I began digging around. I found that there were many references in my build to the original build directory.
I could just keep the build folder the same as it was before or point the compiler to the original directories, however, on other people's machines this might not work if they don't have the same drive letters.
Is there any way to build Qt5 so that it does not use absolute paths? I imagine there must otherwise nobody would be able to distribute it.
You need to add a qt.conf file in your BIN directory.
[Paths]
Prefix = $(QTDIR)
Then set an environment variable called QTDIR with the path to your QT files.
Related
coming from a java and grails background, (and having written millions of lines of C 30 years ago), I cant see how go can be usable with a fixed gopath on windows.
installing go creates this structure
c:\users\me\go\scr
\pkg
\bin
As you will want to have many go projects it seems they have to be mixed together in the same src/kpg/bin dirs, polluting each other. e.g.
/src/project1/hello.go
/project2/hello.go
/pkg/xx
/bin/hello.exe
Which hello.go will hello.exe run?
Unless I am missing something fundamental, this seems crazy - all completely separate projects are expected to share the same package and bin dirs. It means you dont know which versions of which packages, and which exe files belong to which project, and there is presumably plenty of scope for conflicts. I would have expected a /src, /pkg and /bin for each separate go app (like java or grails or even C), and go path is completely redundant, it can be relative to the current project root (like in grails).
To make matters works, for work, we have to use a different directry, e.g.
d:\work\project3
\project4
\package5
\go_utility6
\go_utility7
So now we have a total of 6 separate directories where go progams live. It is not feasible to change the path every time you switch to working on a different project. I guess the other option is to add the 6 paths to the GOPATH. Presumably, all 7 go projects write to the same pkg and bin dir, which is going to be a disaster.
Is there a tenable solution to this situation (on windows at least)?
If we need to add a PATH to GOPATH for every project, what should the file structure be under each project?
E.g. uner xxx\go_utility6, which is a stand alone command line go app, what should the structure be? does there need to be a src dir in there somewhere? does this dir need gopath to point to it? does it need its own pkg, or should it use the c:\users\me\pkg dir?
UPDATE: When I posted this Go did not have modules support and we built and used a tool called vg. These days the recommended way to go is to use go modules.
I use vg for that, it takes care of keeping separate GOPATH paths per project and it switches automatically when you cd a project.
Your example "which hello.exe" should be used honestly makes not much sense. Two tools with the same name?
Even if both are, let's say, an api, your devops will be happier with more meaningful names.
The bin folder is used for 3rd party tools you install, you so not have to install your project binaries. Except they are tools, but then the name should be meaningful again.
You can get more information about the project structure here: https://golang.org/doc/code.html
Since go 1.8 supports a vendor folder below project folders, it is possible to break the original structure. (imho vendors were not maintainable before 1.8, yes that was crazy)
You might want to use a tool like direnv, which would support your desire to change GOPATH per project.
https://github.com/direnv/direnv
It also has some built in function for adding the current path to the GOPATH.
https://github.com/direnv/direnv/blob/master/stdlib.sh#L355:1
For example GoLang also supports handling multiple GOPATHs and per project GOPATHs. So direnv should also work properly.
In my company we have one go folder right next to our other projects.
Under go/src are our projects. No problem so far, since vendors are in the projects' vendor folders and committed.
The so far best dependency manager I would recommend for go is:
https://github.com/golang/dep
I hope that input helps.
With Go 1.11 Go Modules were introduced. You can use Go Modules to have Go projects outside the GOPATH directory.
Here is an example of how to configure a project using GoModules.
My xcode project links to the TestFlight library (libTestFlight.a) and the project is also under git (locally) which I then push up to bitbucket.
I then pull the project down to my macbook pro. However the first build fails because its trying to find the libTestFlight.a file using a path that is relative to my iMac. I can change the project settings and all is OK, but I'd like to avoid this happening on every refresh between machines.
I can't seem to find a way to make the linker find the file relative to the xcode project directory.
If your bundle contains the static library, then in Build Settings you can put the value
"$SOURCE_ROOT"
No matter which machine your code runs in, it will always point to the correct root folder.
The same can be given for Header Search Paths.
Is it possible to build projects to a common directory, instead of the per project bin folder?
The purpose would be to make it easier to source control all my binaries. How can I do it and, what are the pitfalls of this approach?
You have the option to build projects to another directory (a common directory?) rather than the bin/debug and bin/release.
If you mean building your projects and putting the DLL files in a shared folder, yes, we currently do this, but we use this using continuous integration (CI), so we can know when a change in a project caused another project to break.
You may also experience problems when you use a version-specific DLL file as referenced in your other projects.
You can also, rather than having a bat file copy over the DLL files, use Visual-Studio's built in post-build command. It's the same as a batch file, with the exception that no special setup is required in CruiseControl to copy over the files. If a developer makes a change to the post build command it and check it in it will automatically be executed by CruiseControl.
Also, if you'd like your developers to shared the binaries I'd put them in source control to make sure everyone share the same DLL files rather than their own local built copy of the DLL file (which might be different than the actual build server as some compile directives might/might not be defined).
If you mean DLL files/assemblies, then you build to bin/release as usual, then copy the DLL files you require to a common directory and then reference those, so when you rebuild the original solution, you don't have to worry about which version you are using or recompile other related projects as the version hasn't changed in the common dir.
It happens that people build to another folder than bin (e.g. the bin folder in the solution directory rather than the project directory). I doubt you would have any problems doing this. But since you're going to check it in, you must remember to not have it read-only (so you can build over them). Source control programs often lock the files.
You could also consider having a bat script that copies the files to another location after a successful build.
For C++ projects:
Right click on the project -> Properties -> Linker -> Output File
set your directory there.
For C# Projects:
Right click on the project -> Properties -> Builld -> Output Path
I would not put your binary output into source control. Only put the source files, project files and solution files.
We use post-build scripts to copy to the intended location. This works, but is very fiddly (as the scripts are awkward to write & awkward to debug).
I am trying to set up Xcode for a project which contains multiple executables and static libraries. I have created multiple targets and set up the linking and dependencies, and initially everything works great. The catch...
This is an existing project which already has Visual Studio and Makefile builds. Those builds put the libraries in a lib/Debug directory and the executables in bin/Debug. So in Xcode I changed the Build Products Path to "lib" and "bin" respectively (so we can use one set of documentation for all of the platforms). This puts the compiled targets in the right place, but completely breaks both the linking (Library not found) and the dependencies.
I can fix the linking by adding $(SRCROOT)/lib/Debug to the Library Search Paths for each executable (but it feels like Xcode should be able to figure this out on its own, which makes me think I'm doing something wrong).
But — I can't figure out how to get the dependencies working again. If I change a library source file, the library will rebuild but not the dependent executables. If I force a build of the executable Xcode returns success without doing anything; it thinks the target is up to date. If I clean the target and then rebuild it works.
So, any ideas here? Is Xcode being fundamentally stupid in this regard, or is it me (I'm leaning toward the latter)?
Update: I've posted a sample project to demonstrate the issue at http://share.industriousone.com/XcodeDepsIssue.zip. Build it once, then modify MyStaticLib.c and build it again. The executable will not relink (and it should). Many thanks for any help on this one.
starkos, thanks for publishing your conclusion. It validated my experience as well. This situation really screwed me, so it was nice to know I wasn't just missing something.
I did however discover a workaround that avoids creating multiple projects or keeping the library and its dependent in the same directory. It is a hack, but it does work here.
I know it's a bit late but better than never.
For the dependency library, add a "Copy Files Build Phase", with Absolute Path as the destination, and the path text field should be the directory where the DEPENDENT target lives. Then click on Products, find the dependency library (will end with .a), and drag it into the "Copy Files Build Phase." If you now build, this will put the library into its own directory like before and THEN also copy it into the dependent's target directory.
For the dependent, you can now remove the dependency's output directory from the Library Search Paths. This will cause it to find the library copy. If you do this, the dependent will indeed be relinked each time the dependency .a is relinked.
The negatives are, of course, the extra time for the copy, and the necessity to specify (in the Copy phase) the target directory for each dependent of your library. Beats the hell out of the alternatives though....
Xcode doesn't automatically set up dependencies based on use of build products; you have to set up explicit target dependencies yourself.
Project > Edit Target Settings, General tab, + button, add any targets that are prerequisites to building the selected target. That should get you going again.
I've researched this some more and the answer is no, Xcode 3.x doesn't track dependencies between targets that live in different directories. You can work around it by giving each library its own project, and adding each of those to a master project. Or you can keep all of your targets in one directory. Pick your poison.
Here is my solution for this weird behavior in xcode 4.3.1. You have to add build pre-action in scheme:
rm -f ${BUILT_PRODUCTS_DIR}/${EXECUTABLE_PATH}
and choose which build settings to use for this script. Each time before build, target executable will be removed and rebuild completely. It helped for me, and i hope it helps you.
NOTE: Have tried to put this script in project build phase, and result was negative - debugger could not connect process to start debugging.
Good luck!
OK, it would help to have the text of the Linking... build line that's failing. But a couple of things:
1) You shouldn't be linking to anything in $(SRCROOT). That's your project sources. The two places to find things to link are $(SYMROOT) (the Build Products directory) or $(DSTROOT) (the Installed Products directory).
One thing you could do is to have a common Build Directory, then use 'xcodebuild install' action to install the products in the Installation Directory. The other is to use a Copy Files build phase to copy them after building, so you can link against them in $(SYMROOT) but still have them where your Windows compatriots expect them.
THere is probably a way to set up the per-target build products directories correctly, but I'd really have to see the project itself to figure it out.
We have a a product developed on Windows for years. The product is composed of one Eclipse workspace and about 20 projects.
On Windows, we ask every developer check out projects into d:\dev\product folder, and copy a unified Workspace to d:\dev\prod_workspace. This way, whenever a new machine is set, we simply copy files to the same folder, and we can start working immediately.
Now we need to move our development environment to Linux and Mac. But there's no D:\ on Unix. And home folder for Linux is mostly like /home/username and /Users/username for Mac. We found Eclipse keeps absolute path in workspace when referring to projects, so simply copy workspace over does not work anymore. Even when we manually create/configure workspace on a Linux machine, it still cannot be copied over to another user, because the absolute path is changed.
I guess our goal is to allow easy setup of development environment. Do you have any suggestion to move eclipse workspace around?
I develop an Eclipse based product for Mac and WIndows (haven't tried Linux).
The solution I found to work best is to actually go and manually check out the projects in the workspace on each machine directly from source control. While the project structure does convert between platforms, any attaches, such as version-control stuff does not. I am not sure why, but I guess each thing has its kinks.
You may be able to able to hasten things a little by creating a project working set (or whatever it's called, I think it's a PSF file) for a platform, and then reuse it on all platforms.
Another problem is that Eclipse versions are not 100% compatible. One of the problems I have is with manifest files for plugins, which have different semantics (e.g., what to do with exported packages that don't actually exist) in each platform, causing a headache.
Finally, be away that Java on Mac and PC are not identical. In fact, Eclipse has two versions for the Mac. I usually end up running and compiling on Java 5 on the mac, which does have some incompatibilities with Java 6.
I have ported my eclipse project from windows xp to RHEL(never tried Mac)
Your task can be accomplished in the following steps :-
Use workspace variables in your project code rather than absolute path.
Shift your workspace to some location in linux as /Workspace or if you want to keep it user specific make the workspace folder as /home/user_name/Workspace.
There is an option to change all the \ of windows to / in linux. The option can be found under the file menu in eclipse.
Change the settings of where to find classpath directories, the options can be found by just right clicking on the project menu in the project viewer panel.
There is an option to build the project clean from scratch. You just have to click on the option and eclipse would re-compile the project.
Once all this is done, and all your database connections have been successfully ported to linux, you would have a working project running in linux as well.
I can think of two ways to do this:
Use workspace variables in Eclipse to point to the exact location where the workspace sits, if you need that. Then the developer can put everything in the workspace on Windows, Unix, whatever, then define the variable and you're done, or
If compilation is always done from within Eclipse, meaning you don't truly need any absolute paths anywhere, then change the projects to all use relative paths and check the Eclipse classpaths, etc, into source control. Thus, when a developer checks out everything in Eclipse, the classpath and .project file will be at the root level in the project and all paths will be pre-defined.
For option #2, you may need to have multiple .project or .classpath files, and have the developer copy the appropriate one into location. That is, copy .classpath.win into .classpath for Eclipse's use.
If you check out the projects from a source repository, then consider using Team -> ProjectSets to handle these.
Preferences can be saved in a file and loaded.
We tried classpath variables and loathed them. Now we just have everything in single projects in the source repository.
Use the Workspace Preference Transferrer plugin
This allows you to transfer the workspace settings from a given workspace to another via new options in the 'switch workspaces' dialog.
I'll share my own solution:
Zip the workspace. Just zip the entire file and then transfer it over. Then, all you need to do is delete the default drive reference:D:\ ...or whatever ends up appearing in the beginning of your file name. Then all you need to do is drag it over to the new empty workspace on your newly downloaded Eclipse.