Ignore paths???

Hi there!
Have come across a somewhat unusual(?) problem regarding include paths. Hopefully some of you guys have a way to get around it. Here it is:

In a project that I'm involved in some people decided to to use a complete unix path for include files.... Like this:

#ifndef SOME_FILE__
#define SOME_FILE__
#include "/clearcase_rootdir/some_vob/subdir1/subdir2/subdir3/someFile.h"
#endif
The problem here is that I'am on a Windows XP computer and there is no access to this path under windows. The closest one can get is to map a drive letter to the M:\some_clearcase_view\ (the clearcase root in windows) but that would take me to the /subdir1/ level of the above path and not the "/clearcase_rootdir" that I want to get hold of...

Has anyone got any suggestions in how to solve the issue? Anything goes here.
Been thinking about if there are som preprocessor directive that states something like "#ignore path" to include-files and just uses the filename and the std paths specified in the environment and makefile

.. Regards

Some people on your project are clearly idiots then.

I mean, if you change your version management system, or change the vob in which a particular file is located, then everyone on your project is screwed.

The answer is to FIX THE CODE so it's not a problem to anyone.

I'm definitely with Salem on this.

The paths should be described by the build-system, rather than in the source code, if paths aren't "global" in the environment of the system you build in. We have a large number of files in our OS, and the build system has all the paths for building on various platforms and for various configurations. The source and header files may have something like "module/something.h" or <module/something.h> when there may be a naming conflict between one module and another.

--
Mats

Yep Salem. I agree but it doesn't solve my problem.....
One simple way of solving it would be if a preprocessor would have a "#pragma ignore paths" for instance.... Haven't found any of those though :-(

Also agree with Matsp but what can I do apart from trying to find a way around it or stop working in the project....

What you need to do is tell your immediate manager, who can then bring it up with further superiors to eventually fix the problem completely. Continuing to use this mechanism will just make it worse the longer it continues. I presume that you have a project currently that involves building your project for Windows instead of Linux/Unix - and part of that project should be to fix up anything that is incompatible between the two build models.

As a temporary measure, perhaps you can write a script or application that does a search and replace of the offending paths with a more suitable path as a pre-build step.

If you do this right, you should be able to use this to fix up the source code when you have approval of the management, and check the fixed files back into the clearcase repository.

There may be SOME compilers that allow you to say "ignore" or "replace" path as a precompiler command, pragma or command line argument, but I'm pretty sure that is completely unportable, should you find such a solution for ONE compiler.

--
Mats

First thing to do would be to find out how widespread the problem is.

Say, find all source and header files, which have an include which begins with /

Code:

---

find . -name "*.[ch]" | xargs egrep -l "#include [\"<]/"

---

With a list of files, you could then perhaps write a shell script to
- check out each file
- perform some kind of edit on the paths, to make them relative to somewhere useful

Then do some tests to make sure it all works

Then use the same list of files and check them all back in again.

Clearcase has this nifty command line tool called somewhat conveniently "cleartool" which will allow you to do all the clearcase steps you could ever want.

MatsP: The "search and replace" approach is not possible since all files are under clearcase control and they are checked in. I would have to have a script that check out the all files, do the changes but I wouldn't be able to check in the files again for a number of reasons. One is that the people that started this is in charge of those files.

Salem: Yup. Know cleartool rather well... I could of course have private copies of certain versions of the files but makes versioning kinda hard. Once they change something in that file I'm out-of-synch. Also, this is just the one file, FOR NOW. Later on I'm sure that one file includes another that includes a third etc and if all of them has absolute paths... well... need I say more :-(

Quote:

---

Originally Posted by gransken

MatsP: The "search and replace" approach is not possible since all files are under clearcase control and they are checked in. I would have to have a script that check out the all files, do the changes but I wouldn't be able to check in the files again for a number of reasons. One is that the people that started this is in charge of those files.

---

But those people need to know that what they are doing is unmaintainable, and needs to be fixed, which is why I said "go to your superior" (or a more senior colleague that can help bring the argument to the superior(s) until there is an appropriate solution.

Quote:

---

Salem: Yup. Know cleartool rather well... I could of course have private copies of certain versions of the files but makes versioning kinda hard. Once they change something in that file I'm out-of-synch. Also, this is just the one file, FOR NOW. Later on I'm sure that one file includes another that includes a third etc and if all of them has absolute paths... well... need I say more :-(

---

That's why Salem gave a solution as to how to find those files.

--
Mats

Does anyone know of a place where I can find some written hard facts about why having the complete path added to the #include directive is a very bad thing? This is so I can argue for my case?

> Does anyone know of a place where I can find some written hard facts about why having the complete path added to the #include directive is a very bad thing?
You mean other than my first reply?
Or other than the fact that you can't compile on your machine?

Or maybe the manual which tells you that you can, but then tells you to find a better way.
http://modular.fas.harvard.edu/docs/...rapper-Headers

Or maybe the bug report

Quote:

---

Sat Feb 18 2005
- Version 1.2.3
...
- Fixed a bug, which prevented to open #include'd files specified by an
absolute path.

---

I mean, it's such a simple thing to get right, but so far away from "normal style" that very few people ever want to do it.

IMO, the authors should be justifying the use of absolute paths, not you justifying changing them so they work for you.
The code is broken for no good reason, so they need to offer up something really special.

But have you done a search to figure out the scope of the problem?

Not yet, Salem, not yet. Just trying to avoid this to escalate to something unmanageble....
Thanks for all the good advice.

Problem solved. they have deiced to remove the paths
Thanx guys.

Quote:

---

Originally Posted by gransken

Problem solved. they have deiced to remove the paths
Thanx guys.

---

Good to know that at least sometimes, the right decision can be taken.

--
Mats