Thread: Ignore paths???

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

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.

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.

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?
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

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?

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