__FILE__ macro long vs short name

[lpcware]

Content originally posted in LPCWare by fancypants on Mon Oct 20 11:33:22 MST 2014
Hi

I've run into an issue where I'm getting two different sized binary output files for the same code, in two different projects using the "same" settings, causing one of the builds to overflow the flash memory space (and the associated linker issues).

Issue: when building files with asserts, the __FILE__ macro in one of the builds is expanding to a short (i.e. relative) path/filename whereas the other project is expanding to a long (i.e. absolute) path/filename. The long path/filename is overflowing the flash memory space when linked.

Details: I've got an existing project that I've been developing for a while - has upgraded through many versions of LPCXpresso. The settings/builds have been tailored and got everything working as I expect. We're now going to get everything checked into git (using egit) so I figured I'd work everything out by creating new test workspaces/projects, copying/importing the code, configure all the settings, and getting the builds to work as I expect before checking everything into the official git repo. The projects are managed makefiles (created projects with "LPCXpresso C Project"). I finally tracked down why the DEBUG build sizes weren't what I expected: the __FILE__ macro is expanded using a relative (short) path in my original project, and an absolute (long) path in the new project. The root of the issue appears to be in the subdir.mk makefile. The original project's make rule is "src/%.o: ../src/%.c" and the new project's rule is "src/main.c: /Users/........../main.c" (with a unique rule for each source file). When the make autovar $< is expanded in the recipe it is short for the original project's rule, and long for the new project's rule. This results in different lengths of __FILE__. I've looked through the settings for how to make LPCXpresso change the path used in the makefiles but I haven't been successful. Is there a way to do this?

I'm using LPCXpresso v7.4.0 on OSX 10.9 for reference.

Thanks
-Kevin

[lpcware]

Content originally posted in LPCWare by fancypants on Tue Oct 21 22:54:15 MST 2014
I'm no git, Eclipse, or eGit expert (only been using git for a couple weeks) but eGit definitely seems to want you to keep the source/repo (I believe a git "repo" is also the working source files) outside the workspace. It default/automatically puts source files outside the workspace, unless you force it to place it inside.

In any case, thanks for the GitHub advice: the original project I had been trying to setup and configure was already in GitHub. After trying a few different ways to get it working I think I finally figured out a recipe that works (keeps the __FILE__ name short), as long as I change the file layout of the GitHub project's repo to match what eGit seems to like, which is a top level folder name that matches the Eclipse project name; the original repo just had "/src" etc. folders starting at the root.

I'd still be appreciative if anyone has advice on assert() alternatives, but I can start a new thread if you think that'd be appropriate.

Thanks for your help. Much appreciated.
-Kevin

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Oct 21 12:58:09 MST 2014
I think you are confusing a Git repository with the files in your project. As it says, you create the repository external to your eclipse workspace. Normally, this would be on a server somewhere, but can be local to your machine, or cloned locally.You then check-in your project to that repository, first time using Share, but after that you just commit. There really is no need to jump through the hoops that you are trying to, to solve a problem that doesn't exist...

To try this out, why not create a free account on GitHub and play with some of the example projects using LPCXpresso and eGit.

[lpcware]

Content originally posted in LPCWare by fancypants on Tue Oct 21 10:40:25 MST 2014
Here's where eGit mentions this: http://wiki.eclipse.org/EGit/User_Guide#Creating_Repositories. As a matter of fact, by default it wants to put your git/source files in in /User/username/git/....

After reading through your responses (thanks!) I did a few more tests of creating workspaces and projects from scratch. It seems that if the source files/folders are subdirs of the workspace, or linked folders, it creates a relative path in the makefile. If the source files/folders are virtual, it creates an absolute path in the makefile. I could be wrong about the details, but it is something like this.

In any case, it got me thinking about asserts(). They're great debugging and development operational verification tools, but the more you use them in size limited mcus, the more inefficient the code space usage becomes: the strings end up have a lot of redundancy in them (e.g. a rom string with the __FILE__ path embedded every time assert is used). This adds up to a lot of wasted space and ironically ends up making you test less once you start getting to code size limits. I'm thinking the better solution is for me to make an assert() alternative that is more efficient. Just curious - any recommendations of what works for you guys?

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Oct 21 01:28:23 MST 2014

---

Quote:
However, egit recommends that the workspace and source locations stay separate - i.e. the source files are not a subdir of the workspace. Otherwise git will try to include a bunch of files that aren't necessary, requiring extensive .gitignore mods, and Eclipse will try to index and search a bunch of unnecessary files.

---

Where does it say this? We are not big users of Git (we use SVN/Subclipse here) but when I used eGit, there was certainly no mucking about as you suggest. You just need to make sure that you check-in *projects* and NEVER workspaces.

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Mon Oct 20 13:06:52 MST 2014
Are you specifying the variables absolutely or relatively? I suggest you experiment to see what works.

Also I am surprised by your eGit comments. We use Subversion here, so do not have experience with eGit, but that sounds like a very strange recommendation. Have you tried just a normal project structure and see if it causes a problem? I can't see how it can.

[lpcware]

Content originally posted in LPCWare by fancypants on Mon Oct 20 12:45:48 MST 2014
I think you're on the right track...

The files are where I expect them, verified by right clicking on a file and checking the resource properties.

However, egit recommends that the workspace and source locations stay separate - i.e. the source files are not a subdir of the workspace. Otherwise git will try to include a bunch of files that aren't necessary, requiring extensive .gitignore mods, and Eclipse will try to index and search a bunch of unnecessary files. So, maybe this explains the absolute paths in the makefile? It seems like the path can (should?) be referenced from the PROJECT_LOC variable, which in my case is different from the WORKSPACE_LOC var. So, even though the files are outside the workspace, it seems like they should be able to be referenced relatively?

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Mon Oct 20 12:29:38 MST 2014
I would guess this is because the files in the project are not where you think they are...

When you created the project, how did you get the source files in the project? If you used Import, you need to make sure that "Copy files into project" is checked. If you drag'n'dropped them, you need to make sure you choose the copy option.

To confirm, if you right-click on a file and look at the Resource properties I bet it is not located in the project, but is still located in its 'original' directory. This is why make is unable to use relative paths.