N Virtual Folders for one file.

[klaas.holwerda]

hi,

I am trying to improve the Cmake COdeblock generater. I want it to be like VC, meaning source files and headers are grouped per target.
Right now it is more a directory tree, which becomes very deep and not so handy.
Anyway i succeeded to do it using virtualFolders, works nicely. BUT now i have a problem, some target are using some common source files.
But using lines like the next i can only but that common file into one virtualfolder.

      <Unit filename="C:/data/art2d/trunk/wxArt2D/packages/wxart2d/samples/editor/common/screen.cpp">
            <Option virtualFolder="vdrawm/sample_editor_vdrawm/source"/>
      </Unit>

Is it possible to put one file (header or source) into two virtual folders? I tried this, but only the last one is used to but a file.

      <Unit filename="C:/data/art2d/trunk/wxArt2D/packages/wxart2d/samples/editor/common/screen.cpp">
            <Option virtualFolder="vdrawm/sample_editor_vdrawm/source/"/>
            <Option virtualFolder="vdraws/sample_editor_vdraws/source/"/>
            <Option virtualFolder="viewmul/sample_editor_viewmul/source/"/>
      </Unit>

I though virtual folder is sort of a folder with links (like unix), to real files. Is so it should not be a problem to create two links to the same files.

Hope there is a solution, or maybe it is possible, but not yet anticipated.

[Jenna]

Why not using multiple projects in a workspace?

Your approach would mean to copy the concept of projects in workspaces to targets in projects

I don't see the benefit of your idea.

[ultimA]

I support Jens oppinion. Make the generator output not only projects but also a workspace and load the projects into it. Targets are there to select different configurations for a project, it is not a project selector.

[klaas.holwerda]

Why not using multiple projects in a workspace?


Your approach would mean to copy the concept of projects in workspaces to targets in projects

I don't see the benefit of your idea.

I have two "packages" in Cmake, both become a project in VC and Codeblocks. You could say that a package is a set of subprojects, containing libraries and samples. Those all are targets. Libraries in a package belong together, and the samples are based on those libraries.
A package has its own include directories and libraries, flags etc.

A package is a hierarchy of directories, where in sub directories one defined targets for libraries and samples. But on top of that one can tell cmake that a set of targets belong to a (sub)project. The top project is the name of the package. The projects defined in subdirectory CmakeList.txt files, are below that.

The second package uses the first package, but has his own library targets and samples, and include directories, flag settings etc. It calls/uses wxdocview-config(.cmake) to get the settings from the first package. For instance i use 3 packages ( wxWidgets a2dDocview wxArt2D a2dAgg). They are standalone by itself, still i like to develop them together in Codeblocks. Especially when the package are depending on each other a lot, this is handy.

Like in VC i think such a "package"  level is missing. It becomes a flat set of projects coming from all packages.
But in Codeblocks it is possible to use a project as a package. Are maybe i should say a project is a package, which i think it is.
But what about the subprojects i defined within a package. Well it is just a second view on top of the targets. One view is via the directory structure. And the other one is via subprojects. I think that is the whole idea of using virtual folders. Even if i did not defined subprojects, but just want to look at my targets grouped in a different way, that would be done using virtual directories. The only thing is that i can not have the file for a certain target in two different virtual dirs like a link.

But if you forget about subprojects, maybe the next makes it clear why i like to have the second view:

For the wxart2d package my include dirs look like:
c:\data\art2d\trunk\wxArt2D\packages\wxart2d\include\wx\aggdrawer
c:\data\art2d\trunk\wxArt2D\packages\wxart2d\include\wx\artbase

etc.

The source directories are like this.

c:\data\art2d\trunk\wxArt2D\packages\wxart2d\aggdrawer\src
c:\data\art2d\trunk\wxArt2D\packages\wxart2d\artbase\src


artbase and aggdrawer are both library targets. And of course i like to see/browse them in the IDE as follows:

artbase/includes/file1.h
artbase/includes/file2.h
artbase/sources/file1.cpp
artbase/sources/file2.cpp


aggdrawer/includes/file3.h
aggdrawer/includes/file4.h
aggdrawer/sources/file3.cpp
aggdrawer/sources/file4.cpp

It is not a project, it is just looking at the files if a target in a different way.
Not via the directory structure, but via files belong to targets.

All very well possible in CodeBlocks, the only problem again, if a file is shared by two targets there is a problem. e.g. 2 samples use the same file containing some extra code which can be shared by several examples. It is not a library, just some code. That file i can not add to two different virtual directories.

Hope it became more clear :-)

[klaas.holwerda]

A picture might be easier :-)

http://www.wxart2d.org/moin/CodeBlocks?action=AttachFile&do=view&target=dirtree.gif

http://www.wxart2d.org/moin/CodeBlocks?action=AttachFile&do=view&target=virtualdir.gif

[Jenna]

Again:
I don't see, why it can not be done with a workspace, that contains several projects (libraries, exes, samples, whatever).

[klaas.holwerda]

Well i did my best to explain it, don't know what to add to it to explain the problem. But i do think projects is not the solution for it :-(

One can have only one workspace open at the time i assume, and you want me to put in there all the projects flat.
So all the samples en libraries of wxWidgets and wxLua and Agg and wxArt2D etc. in there as projects. All targets in those packages will become projects.

For me a project should contains several targets, and i want to look at the files for each target as a group. And i don't want to see them split up in a tree of includes and a tree of sources. Even if they are on a disk like that. And i think that such a grouping mechanism is best done with virtual directories. What else is their use? To gather for each target its files and transfer it into a project, is i think not the right thing to do.

I really don't understand why there are virtual directories, if it is not for viewing files in a different structure from what is on the disk.

[Jenna]

I really don't understand why there are virtual directories, if it is not for viewing files in a different structure from what is on the disk.

That's exactly the cause why they are there.
But you can have a file one time in your project and not twice.

Using a workspace with several projects, that use virtual folders, in it would do exactly what you want, if I understand your intention correctly.
Only the naming would be different (workspace instead of project and project instead of target).

[klaas.holwerda]

But I do see a file in the normal tree structure and in a virtual directory at the same time, it does not look impossible inside CB, only the project file does not understand it ??

Although in the interface I can indeed only move files, not copy a reference to a virtual folder.
Why there is this limitation on not being able to place the same file in two different virtual folders I don't get. It would make it possible to generate more views on the same set of files on the disc.
I think it would be a great feature :-)

The approach you suggests, is to make each target a project. I think that would indeed allow adding the same source files to N different projects. But does this not go against the idea of a project having several targets? Also, it would mean a completely different approach in Cmake. One needs to generate a bunch of project files. And all the projects files need to be loaded into CB. Like wxLua would need N projects files, same for wxArt2D etc..  And in the workspace I do not see which project comes from which package.
It is a flat list with no hierarchy.

Or should I generate a workspaces instead for each package?? Like for VC, Cmake generates a solution file (sln) containing projects (vcproj). And in Cmake they made include_ms_project statements, to include project files from somewhere else.

Like in de wxArt2D solution/workspace included statements for project from the wxDocview package.
include_external_msproject( docview ${wxart2d_BINARY_DIR}/../wxdocview/docview/src/docview.vcxproj )

I find it Ugly in VC, I hoped CB would be easier, one file for the whole package ;-)

Understand that wxLua and wxArt2D are two different sourceforge projects. You have to generate project files separately with Cmake. Still you want to use them combined in one workspace.

Anyway I better withdraw my patch to CMake using the virt dir approach. The suggested approach generating multiple project files I think I am not able to do :-(

That's exactly the cause why they are there.
But you can have a file one time in your project and not twice.

Using a workspace with several projects, that use virtual folders, in it would do exactly what you want, if I understand your intention correctly.
Only the naming would be different (workspace instead of project and project instead of target).