[Tdg] Code commit

[Alex Norman]

On  0, Rama Hoetzlein <rch at umail.ucsb.edu> wrote:
> some thoughts..
> 
> >I think it should be more like
> >
> >core/{branches/, trunk}
> >core_easy/{branches, trunk}
> >audio_system/{branches, trunk}
> >documents
> >etc.
> > 
> >
> - how often will branches occur?
> - while a future incarnation of mint might warrant such flexibility (to 
> independently branch libraries), are we there yet?
> - how important is it to be able to branch a library early on? (we can 
> also add this later, while it introduces more complexity now)
> - who keeps track of which branches are compatible with one another? 
> (not it)

Well, currently there is no reason to use branches, we can do all of our
development in trunk.  Branches are basically versions that have new
functionality, and that might not be compatible at the point that they're being
built.  Trunk is where you put solid code that works, when a branch is mature
(ie it works and works well), you merge it with the trunk and then that becomes
the trunk.

to begin with we don't need this, though, once the core is developed and the
libraries are developed and working we'll probably want this.
The person who merges a branch is the one who makes sure that it is compatible
with the core.

> 
> >basically, each system, while they require the core, is an independent 
> >project, and should be separated as such. [have their own makefiles, etc] 
> >early in this project we talked about this, we don't want to require all 
> >the libraries, well, we shouldn't build our project up like that either.
> > 
> >
> - to be precise, to build an app or library doesn't require linkage of 
> all libraries.. yet each library does depend on the core. how do we 
> define "independent" in this context (ie. in relation to versioning, 
> branching, etc.)?
> - while there are multiple projects, are they so independent of the core 
> that we would conceive of versioning and branching them this early on?

Well, first of all, our repo is for mint, so there is no reason to have a
core/mint/ folder.. the whole repo is mint.
I guess by "independent" I mean, yes, they depend on core, but audio doesn't
depend on graphics, and when one merges big audio changes in you should have to
even be presented with graphics code, but in the way we are currently organized,
you would.  Changes to Audio and Graphics should be totally independent of
each other.  The first thing we need to do is get the core working, but the API
should be solid enough relatively soon so that we can start building systems.
Even though the API is solid, some of the things underneath might change, this
is "independent" of the audio system because the interface [API] hasn't changed
so as far as the audio system is concerned nothing has changed.
Basically, the core, the audio system, blah are SEPARATE solutions/projects or
whatever you call them.

> 
> >Also, what's with all the folders in core?
> >I assume the platform dependent stuff might go in a "platform" folder, but 
> >most folders simply have 2 files, a header and an implementation file, it 
> >is pain, It makes more sense to me to have all of these implementation 
> >files in a "source" dir [possibly excluding the platform dependent stuff], 
> >and all of the headers in a "include" dir.. or hell, put them all 
> >together... that would make life of makefiles easier, and, the core 
> >shouldn't be that big, so managing 1 "source" directory won't be a problem.
> > 
> >
> - what happens when memory_pool (or event_queue) for example, which is 
> currently 2 files, develops multiple subclasses?
> - do we want all the subclasses of logical groups (memory_pool, etc) to 
> be flat listed in a single folder? for example, all subclasses of 
> memory_pool to be in the same folder as all subclasses of event_queue 
> and application, and timers subclasses on different platforms?
> 

Well, like I said, I think it is a good idea to have platform dependent code
separated, but having all the cpp files [per "project" (ie core, audio)] that
are platform independent in one folder simply makes life easier.  Maybe it'll
also help us keep our code size smaller?  I think, for now, it makes things
easier, if it becomes a problem later, we can change.  But systems should NOT be
that large, and the core shouldn't either, we should make sure of that, so there
won't be that many files to deal with and most people here use some IDE that
abstracts away the concept of "file" anyways right?  So it doesn't really matter
to you folks once you get the shit in your IDE.

> >so I propose we do this:
> >svn/core/branches/source/[all the cpp files for core]
> >svn/core/branches/include/[all the header files for core]
> > 
> >
> - makes sense if there is just a single folder for each library. do we 
> really want this?
> - if we do group "components" (such as memory_pool, event_queue) into 
> folders, would it be better to keep the .cpp and .h files together or 
> use some other structure (two folder trees, folder tree for cpp but not 
> for .h, single folder tree as we currently have)?

so, I think it make sense up until the svn/core/branches/ part at least..
I also think it makes sense after that but that is up for discussion, but one of
the annoyances of these separate folders is this:

say I have:
foo/{foo.h,foo.cpp}
bar/{bar.h,bar.cpp}

foo has a class Foo in it
bar has a class Bar in it that inherits from Foo

to build with g++ you have to include both of those folders:
g++ -I./foo -I./bar foo/foo.cpp bar/bar.cpp main.cpp

and since we have like 12 folders, there is a lot of that B.S.
if we had all the source [cross platform] files in one file and all the [cross
platform] headers in another we'd do this:

g++ -I./includes source/foo.cpp source/bar.cpp main.cpp

basically it makes MY life as a makefile maker a LOT easier and doesn't really
cause any harm for those of you using IDEs.

> 
> questions we have not really addressed until now i suppose. i'm not sure 
> i could address all these myself now anyway - not only because i can't 
> yet forsee their impact, but because i have to finish my thesis, among 
> other things.. on a personal note, nothing is perfect the first time. 
> and we can't forsee everything. i would prefer to stick with what we 
> have for now, do makefiles (PS. i spent weeks building vs projects), and 
> move onto coding... then come back and revise later as i'm sure we'll 
> need to do anyway when we have a clearer picture of what we really want.

I agree that nothing is perfect the first time but I can see what is wrong with
what we have RIGHT NOW and I think we should fix it before we move on.  If that
in turn causes problems down the line we can fix them then but right now the
current setup causes problems as I see it.  I understand that you've invested a
lot of time in the the VS project, but that is no reason to stick with a setup
that is too compilcated and actually "incorrect" as I see it when we can easily
change that.  We should change it now before we become too invested in it.  at
the very least I think we need each system to have its own top level folder and
to reduce some of the folder redundancy.

-Alex

> 
> rama
> _______________________________________________
> Tdg mailing list
> Tdg at mat.ucsb.edu
> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg