Bug 266764 - sharing files among projects
Summary: sharing files among projects
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-build-managed (show other bugs)
Version: 6.0   Edit
Hardware: PC Linux
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-02 17:58 EST by Miwako Tokugawa CLA
Modified: 2020-09-04 15:19 EDT (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Miwako Tokugawa CLA 2009-03-02 17:58:42 EST 
I don't know about other people, but I personally find the ability to have more than one targets (ex. 1 executable and 2 static libraries) in one project very useful. This is because the makefile-based project (that's not in CDT) I'm trying to convert to CDT managed project just does this. For example, a header file may be referred to by more than one builds, and options may be common to more than one builds.
If you think this feature would benefit users in general, please give this or an alternative a thought.
Comment 1 Miwako Tokugawa CLA 2009-03-09 18:58:03 EDT 
What may be as useful is the ability to create a new "file link" (instead of a new file) in a project.
Suppose a.c is used as part of Projects X and Y and is compiled using different compiler options in both (or is compiled using different compilers.. or whatever, in which case ProjectX(/Y) can't just link in a.o built in ProjectY(/X). As it stands now, I'm forced to make a copy of a.c so that it can reside in both project... This can cause maintenance issue (due to cvs update, etc.)
Comment 2 James Blackburn CLA 2009-03-09 19:05:11 EDT 
(In reply to comment #1)
> What may be as useful is the ability to create a new "file link" (instead of a
> new file) in a project.
> Suppose a.c is used as part of Projects X and Y and is compiled using different
> compiler options in both (or is compiled using different compilers.. or
> whatever, in which case ProjectX(/Y) can't just link in a.o built in
> ProjectY(/X). As it stands now, I'm forced to make a copy of a.c so that it can
> reside in both project... This can cause maintenance issue (due to cvs update,
> etc.)

Does creating a linked resource not work for you? I know in the current platform linked resources must be absolute or relative to some workspace defined variable, but this should work (at least I'm doing it...).

If you're more adventurous, you could start tracking some of the resources changes in e4.
Comment 3 Miwako Tokugawa CLA 2009-03-09 19:28:23 EDT 
Thanks, yes it would. 
I still think the initial setup would be easier with the "link" ability if I am distributing the projects to others.. (can't they just refer to .cproject's?) but I'll have to see..