> I don't plan to add subproject layout support to hbmk2
> itself ATM, but it seems to be easily doable by calling
> hbmk2 with .hbp files in _proper order_. Such job can be
> done by hbide.
I agree. I think that the concept would be encapsulated in hbIDE, not in
hbmk2.
> To be more precise hbmk2 already supports multiple
> projects, but caller should provide proper ordering
> of these projects:
>
> - myapp.hbp
> - mylib1.hbp
> - mylib2.hbp
> - mysublib1.hbp
>
> =>
>
> hbmk2 mylib1.hbp mysublib1.hbp mylib2.hbp myapp.hbp
>
> Maybe later we can introduce a concept of .hbs ("solution"?)
> file which could describe such tree layout which can
> be internally converted to .hbp filelist in proper order.
>
> Or alternatively some sort of cmdline markup to denote
> such tree: hbmk2 myapp.hbp (mylib1.hbp, mylib2.hbp (mysublib1.hbp))
This could be made by hbIDE, based on own project file describing the
hierarchy of the project.
I think a xMate's .xbp counterpart will a must for hbIDE to treat a project
as a organic object.
>
> If someone develops such parsing and tree flattening
> logic separately from hbmk2, it can be moved to hbmk2
> even easier at some point.
Also, but seems to overload the hbmk2 mission.
> I do this very easily:
> hbmk2 lib1.hbp lib2.hbp app.hbp
Yes. I realize that, but i was meaning at edit time. In xMate the subproject
are seen as part of the main project and isn't nedded to jump from one
project to other in order to edit the sources. Other project managers treat
each project separately and is time consuming and confusing to manage
related sources contained in different projects.
Best regards,
Maurizio
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
