I'm working on a project in CodeBlocks and am being inconvenienced by the project tree.
Let's say I have two C files: foo.c and foo.h. These files live in physical memory within the FooFolder directory.
When I import the FooFolder into a CodeBlocks project, the project separates them into a Src folder and Header folder. However, I would rather be able to just have a folder called FooFolder and let foo.c and foo.h live in there as they do in physical memory.
Is there any way to do this in CodeBlocks?
Thanks!
In the workspace tree-view, right click on Workspace and un-check the item Categorize by file types
Related
I tried to add my USART library to my project but I am still failing to properly add it so it will be recognized.
I created an USART.c and USART.h file, which I want to add. This is what I tried:
1) Right Click on the Solution / Properties / Toolchain / Directories
2) Adding the Path where I got these two files
When I try to build the project, it did not work. I get the message undefined reference to 'initUSART'.
How do I add my own libraries to projects then?
The screenshot in your question shows that you arranged for the compiler to find the header files for your library. But you also need to use the compiler to compile your library functions (e.g. initUSART) and create a static library file (with a lib prefix and a .a extension). You would need a separate Atmel Studio project for that, or learn how to use the AVR GCC toolchain outside of the IDE to compile libraries. Then you need to put that file in a directory that is in the linker's search path for libraries, and then you need to pass the appropriate -l argument to the linker. For example, if your library is called libuart.a, you need to pass -luart to the linker. The Project Properties for an Atmel Studio project has the relevant settings you need to configure.
GCC has a standard way to compile, create, and link to static libraries, which I outlined above. You can learn about that from any tutorial on GCC static libraries. You then would need to apply that knowledge to the AVR GCC toolchain, and find the appopriate options inside Atmel Studio that you need to set.
Aside: Atmel Studio does not make it easy to use libraries at all. The Arduino IDE does a much better job because you just put the source files for the library in the right place and it compiles them for you. There are a huge number of Arduino libraries too; you wouldn't have to write your own UART driver if you could use the Arduino platform.
The simple alternative: If you don't know much about compiling and linking to C libraries and configuring your IDE, you would have a much easier time just copying the library files into your project, adding them as source files, and letting Atmel Studio compile them just like any other source file in your project.
Another simple way of adding folders to your project is to copy/paste the folder into your project and then open Atmel Studio.
On the right side (where is by default Solution Explorer) you'll see all your files except the ones that you just added. Now press the Show all files and search for you folder which should appear grayed out. Right click on it and Include in project. That should be all!
This image should help
I got another solution that might help . i found Include Directories in this path for MegaAvr(8bit) :
C:\Program Files (x86)\Atmel\Studio\7.0\packs\atmel\ATmega_DFP\1.6.364\include
Just Puts All your Library in one Folder And Copy All of It in this path , then include it like another library . For example I created a folder named "ali" in that path , then i copied all my libraries in this folder (like alcd.h , usart.h) and then included in my programes with this :
#include <ali/usart.h>
and done ! just remember to backup your folder before Windows Installation (Drive Format) . Also you can find your libraries (.h and .c) in Solution Explorer -> Dependencies after Code Compilation .
GoodLuck ...
inside Folder
including xio.h in folder ali
xio.h in dependencies after compilation
my folder in specified path
If I add a source file to a Code::Blocks project via File>-New->Class... ;
It will put a .h file in Headers/include and a new .cpp file in Sources/src. I don't understand the reason for the subdirectories under Headers and Sources. Are there files that would go under Headers and Sources but not in the include or src directories ?
The Code::Blocks project view classifies files as "Sources" and "Headers".
This is just a logical classification that is supposed to be helpful: when you create a project you don't
actually get directories called Sources and Headers in the project
directory.
But when you create a class, MyClass, the source .cpp file and the header
.h must physically reside somewhere, and by default Code::Blocks saves
MyClass.h in a directory called include and MyClass.cpp in a directory
called src, both under the project directory. Then include/MyClass.h
appears under Headers and src/MyClass.cpp appears under Sources
This is a reasonable and conventional default for any simple project. If you
want your files organized in some different way, then you can specify
the directories in which the .h and .cpp will be saved in the
Create new class dialog. You can specify that they will be saved
in the same directory, say UserInterface; then UserInterface/SomeClass.h
will appear under Headers and UserInterface/SomeClass.cpp will appear under
Sources.
You can create whatever subdirectory organization makes sense for your
project's structure - or none. But the source files will show up in the
Sources tree and the headers will show up Headers tree.
By way of background, I'm trying to get one of the Emgu CV examples working. It is the Motion Detection example mentioned in the answer to "Looking for a function for motion detection on emgucv"
To get the example code working I need to add references to the Emgu CV DLLs to the project and also make sure that the relevant Open CV DLLs are copied to the output executable directory of the project build. The relevant DLLs are listed on the EMGU wiki.
I'm adding the Open CV DLLs by adding them as content to the example project and marking them as "Copy always" in the content properties:
I do not want these cluttering up the root level of the project so I have added a project folder to put these DLLs in:
However when I build the project the DLLs are copied with the same directory hierarchy, i.e. they have an enclosing folder within the execution directory which I do not want:
What properties do I need to set to ensure that the DLLs are copied into the execution directory but into its root rather than in a sub directory?
========== EDIT ==========
Note that I cannot add these DLLs as references to the project as they are neither .Net assemblies nor COM components but the Open CV C++ libraries.
Talking to another developer at work he uses another workaround. He keeps the DLLs in a project folder and then adds a post-build event in the project's property pages to copy the DLLs into the directory with the executable:
copy/b/y "$(ProjectDir)Libs\*.dll" "$(TargetDir)"
user7116's advice and my colleague's are great workarounds but I'm going to leave the question open just-in-case someone discovers (or Microsoft adds) a way to actually set properties on the content files to ensure that the DLLs are copied into the root of execution directory rather than in a sub directory.
Our group keeps the files in a folder similar to you, however instead of adding the folder to the Project, we reference these DLLs in your main project by adding the items as a Link to the top level of your folder:
As before, set each item as Content and Copy Always (items shown in a solution folder):
Then when you build they will make it to your output directory:
It isn't as pretty--you still see them all in your main project--but it at least puts them in the right place.
Like many people, I would love to have Xcode use a folder structure that mirrors the folder-structure on disk. However, I cannot get the code in "folder references" (the cyan folders) to show up in my project targets under "Compile Sources." Is there any way to do this?
I have managed to even add a cyan folder to the "Compile Sources" build phase, but that does not result in the contents of that folder being added.
How can I use folder references for code?
The simple (and very unfortunate) answer is that Folder References under Xcode remain broken and buggy, they don't work. Tested 04-Mar-2017 in Xcode 8.2.1
Below is an example exploration so you do not have to waste your time replicating the Xcode failure.
(incidentally buggy Xcode crashed twice while I was producing this example)
Per the question, the overall desire is to use a folder reference in Xcode so Xcode picks up all the files in the folder and includes them in the project, and by proxy will update automatically based upon any Finder or Xcode changes of the folder. In this way 50 projects all leveraging the same set of common source code files do not have to be individually updated when those folders get changed. Below explores how this is broken in Xcode (tested in 8.2.1)
The example: ViewController.m includes NSError+Core.h so we want everything from the folder "NSError+Core" to be added to the project.
NSError+Core.h is in this centrally located development folder
Drag the source folder from the Finder into the Project under the "Support" group (nothing up my sleeves, simple drag)
Xcode dutifully offers to add the drag to the target, note the "Create folder references" is selected, not "Create group references". Note also it is clear that Xcode is offering and is told to add this folder and files to the targets.
Although everything looks like it should work, the compiler does not pick up the header file and a recompile yields the same results... can't find header. Ditching the DerivedData does not help either.
So doing a double check, we check the "Compile Sources" under the project and sure enough, the source file is not there either. Remember, Xcode 'added' it to the target...
So what if we drag it from the folder into the "Support" group...
It offers to add them to the project again?! Note that the settings are identical to the first time they were drug in by virtue of the parent folder drag instead of files...
And now the source file shows up in the "Compile Sources" list. Note the bizarre double listing of the files in the project.
(Xcode crashed shortly after snapping this screen shot)
And of course the compiler can now find the header file and the error clears on the import as it should have the first time we drug it in...
Did it just need a little help to "find" the file? If so, the "Create folder references" does exactly what?
So we try and tidy up and drag the files back from the parent "Supporting Files" group to their rightful folder. Without any confirmation, indication, notification, the files just vanish from the group and nothing happens in the NSError+Core folder.
Oh by the way, it really did delete them from the project too... The Compile Sources no longer has the NSError+Core.m reference.
SO to sum up, "Folder references" as implemented thus far do not seem to have any useful purpose... It would appear to be a 6+ year old dunsel on the USS Xcode.
Kevin - linked source folders, folder references, etc, are super useful for when you have a common code base shared across different IDEs, like I do for my games that I compile on Windows, Mac, iOS, Android, Linux, etc. I have 3 different IDEs all building the same shared codebase, so it's very helpful when one automatically picks up on a new file and adds it right into the project after I merely run svn update, and I svn commit from one IDE (say XCode) and my Eclipse in Windows project picks up the change. I have a different project for each because each IDE likes the project files in a certain configuration so it's easier for me to have multiple SVN directories (base-project, project-ios, project-android) that all share code in base-project than to have one mega project directory with the different IDE bits unhappily all shoved into subdirectories (which is what I tried the first time around).
Furthermore - it used to work fine in XCode 3. They seemed to not like that useful of a feature so it is no longer working in XCode 4 as I've just found out.
I just tried doing this to share code across multiple Xcode projects, and our team came to the conclusion that it's better to create an Xcode project that contains all of your shared classes, compiles them into a static/dynamic library, and then add that as a subproject to those that need the shared code. Then you can set up target dependencies and link your shared library. This will get you the "automatic updating" every time you add a new class to the shared library project.
This approach also works well with submodules or even cocoapods/carthage.
You can't. Why are you even trying? A folder reference's job is to embody a folder, without having entries for all the individual files in the folder. It's primary use is for copying an entire folder of resources verbatim into a project. If you want to compile the sources though, then those sources must be referenced in the Compile Sources build phase of the target, which requires having individual entries for each file.
Depending on what's in the folder, it might make more sense to have a Makefile or some other external build process that builds the content in the folder into a static library. This way you can invoke that build process from a Shell Script Phase, and then just link in the resulting static library. Alternatively if you're using this folder as a way to have a shared bit of code (e.g. an svn:externals or git submodule), you could give that folder its own Xcode project and then embed that project into any of your other projects which share this folder.
I have a directory of source files (.h and .m) that are shared between multiple projects. I'm not building them as a static library; instead, I just include the source in each project.
Previously, I was copying the source into each project independently, but now, I'd like to move to having a single directory that has all of those shared files it, and include a folder reference to them in each XCode project that uses them.
Including them as a folder reference (blue folder) is no problem, and I can add the path to the header includes so that the files in the project can see them. But they're not being built, and thus I'm getting link errors.
How do I get Xcode to build the source in the external directory?
folder references don't work like that in xcode.
this is exactly what an external target (e.g. static library) is for... seems strange that you would choose to duplicate (a portion of) the maintenance for every project. with a library, you can also reduce the build and indexing times (assuming the build settings match some of the time).
if you insist that a static library is a bad idea... you can approximate what you want by creating a custom build script phase for your target (you will need to configure a script, rather than passing the xcode folder reference as input).