folder structure for object file

[dgel]

Hi,

I'm not sure if this is intended behaviour, but when I compile a project in, e.g. /home/un/project/ the object files are placed in the folder: /home/un/project/o/home/un/project

I really don't see why the folder structure needs to be replicated completely, can't the .o files be placed directly in the o/ folder? with the minimum of folder structure replicated? Or does that complicate matters?

[bneijt]

The resulting structure, which I agree seem stupid, has the following history: 1) Having an "o" directory in every subdirectory of the source seemed wastefull, this also made it impossible to relocate the "o" directory to /tmp/build_o/ using a symlink (sounds weird, but with NFS the /tmp directory is much faster then home, which made sense). So: I wanted a single "o" directory, to make sure that a "--o-directory-at=" feature would be possible in the future and hackable using a symlink.

2) Once in the single "o" directory, the object files need to be in directories to keep collisions from happening (.cc files in different directories often end up with the same names, like operator.cc). So, the source directory structure was mirrored under the "o" directory.

3) Then somebody came along who used the following:

projectA/src/something

projectA-common/src/something

where an include in projectA/src/something actually pointed to "../../../projectA-common/src/something/something.hh". This means that I needed to make sure that within the "o" directory, there would have to be some extra information.

I tried MD5(absolute_path_to_file.cc), but that only meant it made it impossible for humans to read and I would have to still find a place to store the .md5 and .gch files. Not a good enough option in my book.

This is why I decided to add the absolute path of the file under the "o" directory, allowing you to share the "o" directory among differently rooted sources.

I had the great hope of creating a global-shared-all-mighty "o" directory in the near future, where every user would use one o cache for all their projects, but I havn't done that yet and I still havn't solved the problem of keeping the size within bounds (how to keep just enough o files in that global cache).

If you have any idea about the situation, feel free to post a comment.

[dgel]

Thanks for answering my question, it does make sense this way. Given that you have the full path of every folder in which you compile source files, you could of course identify the largest subpath all these folders share and replicate the minimum of folder structure, but in reality this might not help very much. E.G. in the case of your example if the compile build command was given in projectA/src/, create the folders:

root_path/projectA/src/o/projectA/src/etc and root_path/projectA/src/o/projectA-common/src/etc

or, alternatively create the object folder as: root_path/o/ With then the same subfolder structure. This second option means that you might want to create a folder where you don't have write permission or where the user doesn't want any files made though.

So yeah, either keeping the way it is now or cutting off the maximum you can off the beginning of the paths seems the best way.

[bneijt]

The "find the minimal subpath needed" seemed to complex for me to correctly implement, as it will change as soon as you include or exclude files from that path... and you don't want to recompile everything after a single include change.

Using a higher-level o directory is a solution I had never considered before. One problem I see is that there is no garantee that you are allowed to write in that higher directory. Going for a global and configurable o directory which lives in /tmp by default may still help though. Food for thought! I'd have to think about it.