RE: [cdt-dev] how to build multi level targets ?

[kesselhaus@xxxxxxx]

Thomas, I hope, you don't blame on me.
I just gave one more answer as his last opinion was not glad about creating
20 projects.

Sure, it would be better to have many projects, with the advantage of
smaller and faster indexes and index-operations, project dependencies on
interface boundaries, multiple projects may depend on one lib and get
updated, if that lib has been changed in Eclipse, etc. pp.



> > -----Original Message-----
> > From: cdt-dev-admin@xxxxxxxxxxx 
> > [mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf Of kesselhaus@xxxxxxx
> > Sent: November 26, 2004 1:19 PM
> > To: cdt-dev@xxxxxxxxxxx
> > Subject: Re: [cdt-dev] how to build multi level targets ?
> > 
> > > > 
> > > > Create 20 projects ins't quicker than creating 20 Make Target ?
> > > > 
> > > > Have you anything   more efficient ?
> > > > 
> > > 
> > > Not particulary, Eclipse does not allow subprojects(projects within 
> > > projects).
> > > Maybe you can bring your case to the Eclipse platform case.
> > > 
> > 
> > Or write a "Super"-Makefile in your project root, which calls 
> > all Makefiles in each of your subdirectories in your project.
> > 
> > project
> >   +--- proj1
> >   +--- proj2
> >   +--- proj3
> > -----------
> > MAKE := make
> > 
> > .PHONY all debug clean proj1 proj2 proj3 TARGETS := proj1 proj2 proj3
> > 
> > all : $(TARGETS)
> > 
> > debug : $(TARGETS)
> > 
> > clean : $(TARGETS)
> > 
> > proj1:
> > <TAB>$(MAKE) -C $@ $(MAKECMDGOALS)
> > 
> > proj2:
> > <TAB>$(MAKE) -C $@ $(MAKECMDGOALS)
> > 
> > proj3:
> > <TAB>$(MAKE) -C $@ $(MAKECMDGOALS)
> > 
> > proj4:
> > <TAB>$(MAKE) -C $@ $(MAKECMDGOALS)
> 
> Of course this approach will cause certain concepts to flow over.  Now
> you have a single project that contains what (may be) multiple independent
> projects that are related, but actually independant.  For example a number
> of utilities all in the same package.  This means that things like
> searching
> and refactoring will take the entire super project into consideration.
> Other
> items like automatic compiler setting detection may be made more
> complicated.
> 
> If the projects are truly independant, then you should likely create
> separate
> projects for each directory and then if you want a "unified view" project
> you
> could create an extra top level project and then using linked resources
> link
> it to the top level directories.  
> 
> If it is just visual distinction you are looking for, then working sets
> can
> also be used effectively to cut down the noise of having a lot of top
> level
> projects rather than using project nesting.
> 
> Just a few thoughts ... your mileage will vary and I would encourage you
> to
> try out all of the different options to get a feel for what works best in
> your
> scenario.
> 
> Hope this helps,
>   Thomas
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
> 

-- 
NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl
GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis!