I am writing an application that generates .xcodeproj files. It's generated a .pbxproj file, however when opening it in Xcode, I get an error message, "cannot be opened because the project file cannot be parsed." and nothing more.
Is there a reliable application for syntax parsing old-style plists?
If it requires me to use low-level Cocoa APIs, I'm fine with that, but some pointers at least?
You should take a look at Xcodeproj.
It's not a linter, but it may help you to understand why your project isn't being opened correctly.
You have a few options:
Try to parse your project with Xcodeproj to see if it gives you more useful errors.
You don't mention what language you're writing in, but if it's ruby, you could simply use the gem directly.
See if you can call the CF calls directly. You'll note that the part of Xcodeproj that actually writes to the file calls this c extension which simply uses CFPropertyListWriteToStream.
This all assumes that your problem is one that could actually be solved by a linter. If your formatting is correct but you're writing values that somehow confuse Xcode then these suggestions may not apply, although I do think reading through the Xcodeproj source would help you.
Related
I am writing a typical Qt (4.8.2) app with plugins. One of the plugins includes a couple custom interfaces, by calling the Q_INTERFACE macro. Those interfaces are found in .h files visible to the project (via the .pro includes) and they all contain a macro call to Q_DECLARE_INTERFACES.
Yet upon compiling the moc file I get an undefined interface error in the main .h file of the plugin. It doesn't tell me which though, it only specifies the line of the first (I tried changing the order but it makes no difference - unless all interfaces are affected - heck, who knows, that could be the case.)
This plugin works at other people's desks. Some of the stuff in the main app is written with Qt 5 but always with macros to check for the version and include other code for earlier versions like mine. This also works at other people's desks who work with 4.8.2 for their plugins.
Where to look for the cause of that error ?
I don't know why my question got voted down, but here's the answer :
With the copy of the project I also received the moc_*.cpp files and some files called mocinclude.tmp . This was a first git add mistake.
But there is another problem : at least the latter (if not the former) does not get cleaned properly or recreated by Qmake/make clean.
A third problem : In mocinclude.tmp there were absolute file paths from the computer where the project was first created, which wasn't mine. Relative paths would have been less error-prone.
Those wrong absolute paths led to the "undefined interface" error (which is nothing less but a "file not found" error in the case of a needed interface file) when compiling the moc files.
Deleting all mocinclude.tmp (and moc files) solved my problem.
(I also made sure to tell git to not track them anymore.)
I have split my less/css into several files grouped by certain categories, so the single files stay easy to maintain. Though I only want to have one css file which gets imported into the layout.
For this I have - how I call it - a master less file which imports all the others like config, forms, layout and so on.
Now the problem is, that for example WinLess or all the other copilers i tried, only monitor the save of my master file, and only then compiles it. However this is stupid, because this file nearly never gets any changes. So what I would like to have is something, that detects changes on the imported less files and then only compiles the master file.
Does anyone know any tools, which are capable of that?
Or how do you manage your less files to bypass this problem?
Further Info: I have mapped the server directory locally via SSH and edit the files in there, i.e. the files are only pseudo local. They are on the server but accessible with a local path over a drive letter. The compiler should be able to work with that setup.
Thanks for the answers!
In all honesty, your best bet is to actually use Less's own compiler which will of course be the most up to date option. It will be done through command line but it's the best way to know that everything is correct, working and up-to-date.
All the information can be found in the Less Documentation Here
More information about compiling with imports can be found HERE
The latest version of WinLESS does report that it has automatic re-compiling when an #import file is changed so it could be that your version of WinLESS is out of date. (See HERE - 3rd bullet point under Features)
Alternatively, see if you can get it to work on purely local files. If this works, it may be an issue with the compiler not being able to do asynchronous checks over SSH.
I use Notepad++ with the NppExec-plugin on-save script. If you make a convention decision to always name your primary file "master.less" you can use this script:
NPP_CONSOLE 0
NPP_SAVE
if $(EXT_PART) != .less goto end
"C:\Node.JS\node_modules\.bin\lessc.cmd" -x "$(CURRENT_DIRECTORY)\master.less" > "$(CURRENT_DIRECTORY)\master.min.css"
:end
You can do something similar with any editor that supports batch scripting (like Stewartside suggests)
I'm frustrated by the lack of flexibility in the Visual Studio project/solution, but I realized that now that it uses MSBUILD it might be quite powerful but just doesn't expose that to the IDE. So I took a look at MSBUILD docs and don't know where to start! I wish there was a Nutshell book for that. Is there any good tutorial someone could point me to?
More specifically, here is the kinds of things I want to do:
Run a utility pre-processor to generate .CPP and .H files, which are then used by a regular C++ project. There are multiple inputs (to figure dependencies of; specifically should know if a normal .h file it uses has changed) and multiple outputs (at least one .cpp and one .h file) that are used as files in another project.
FWIW, the most complex case involves using Qt in a "normal" C++ project that can be built using VS Express 2010 or MSBUILD directly from a script on a server. Since that is a common library, there might be some guides or whatever to help? Note that a VS plug-in is not useful for the building stage, but could be used to initially generate project files that then rely only on MSBUILD and stuff included with the source code.
Would somebody please point me in the right direction?
--John
It gets worse from there, but that's my first goal.
I found the kind of information I was looking for in a book MSBuild Trickery: 99 Ways to Bend the Build Engine to Your Will by Brian Kretzler.
In the first 18 pages I found a few key pieces of information that, along with the on-line documentations I've already gone through, helps clear things up enough to try tackling my project. Details of interest include the processing order of how MSBuild reads and operates on the things in the file, quick points on when wildcard in items are expanded and how to handle generated files, and how to see what's happening in some practical cases or even step in the debugger.
FWIW, I managed to attack my problem without using the murky ".targets"/rules files that I have yet to understand, but only using better documented/exampled features (in particular, a Target that has wildcard items doesn't care that the file name extension is not in any ".target"; is simple enough to copy from example and allows the files to be seen in the IDE Project and added to the list using the IDE; again, the FileExtension there just works OK.)
I am trying to compile a Qt Library Project to use its DLL as a plugin of my Main Application.
I've come across this particular error and I cannot seem to get past it, no matter what I try.
I believe cluttering the question with code tags is pointless when I can just provide you with the "working issue" (for lack of better wording).
This is a link to both projects. The main application AND the plugin I am currently testing on.
(please remember to modify the path in the Application project of the dll. I am using absolute path, which will most likely never be the same one you will use. I used absolute paths to make sure the problem was unrelated to finding the file itself)
So far I've checked:
My Qt version is, indeed, 4.8.2. Built with VS2010 Command Prompt.
As far as I understood the documentation, my code (particularly the APlugin project) follows the documentation instructions word by word. There's some space for human error, but I believe I got it right. as specified here(The Lower-Level API: Extending Qt Applications)
I am able to generate other QPluginLoader::errorString() errors (for example, using an invalid path to the .dll file will return a "file not found" error). Thus diminishing the margin of error in its use.
As of today, Google results are, at best, cryptic and/or do not apply to my current context of development (I am on VS2010, Win7 N Ultimate, Qt 4.8.2)
I believe it's better that I provided projects where the issue is reproducible, instead of just cluttering the question with code, but if you think I still should copy-paste my code, let me know and I will provide it explicitely in the question.
The only thing I am able to provide so far is that, albet I don't use a .pro file, I shouldn't need it, because my application will be windows exclusive, and the vcproj file already contains that data.
I am trying to build QtCore.lib and I get this weird error.
PRJ0019: A tool returned an error code from "MOC kernel\qtimer.cpp"
I am able to build qtmain.lib but not able tp go any further.
moc.exe is available in bin folder and the path is added to my PATH.
kernel\qtimer.cpp file is also present in corelib folder.
Any help in this regard will be appreciated. I am building with Qt-4.5.2 source.
In Qt 4.5.2 moc.exe has some issues. An email I sent to Qt Support mentions it moc'ing files that were not modified. It could have further issues, which could be related to what you are experiencing.
Sorry I can't recall the exact details. To make things worse the link Qt Support had sent me at the time is broken.
They had suggested using 4.5.3. I think we ended up staying on 4.5.1, which we are still using today, although the move to 4.7.x. is occurring as I write this. :)