[Tdg] Mint updates
Alex Norman
alex at neisis.net
Wed Mar 7 14:19:21 PST 2007
Okay, so before you sent this email I made the changes that Wes and I agreed on,
you basically said it was cool and Graham, while not specifically approving this
folder structure said things needed to be moved around basically in the way that
I did it.
I figured the build stuff is all platform specific, might as well put ALL
platform specific stuff in there so we don't get confused about what is what in
the source folder.. like inttypes.h, if that is in "include" and I -Iinclude in my
makefile, which types.h am I getting? my system inttypes.h or the windoze one??,
if we keep that out of the common includes then we don't get that problem.. I
never get anywhere near anything that isn't either cross platform or my
platform..
this all CAN BE UNDONE, so don't worry.
the thing you're talking about, people making major changes that break other
people's code, That is what branches are for.. people make these major changes
IN the branches, so that the trunk is ALWAYS stable. Once people approve of a
branch then it gets merged into the trunk and that becomes the trunk.
Everyone,
check out the project base:
tdg/svn/mint
tell me what you think, if people think it isn't up to par we can move stuff
around more, or revert to the thing from before.
-Alex
On 0, Rama Hoetzlein <rch at umail.ucsb.edu> wrote:
> I thought we had decided to keep the make files seperate from the code?
> I can see some seperate os-folders for make files, but why not just keep
> all the code together.
>
> I agree that the folder structure needs some revision. While folder
> structure might not seem like a big deal, please don't commit the folder
> changes until there is unanimous consent from the group. I still have no
> idea what Graham and Lance (Jorge?) think about this (unless they have
> no opinions on this issue). I think getting feedback from everyone, and
> moving forward only after unanimous consent has been a valuable
> principle in our operation as a team... In the event stuff, for example,
> I tried to make it my own personal practice to actively confirm
> agreement with everyone in the team before posting anything - thats why
> it took so long, but the result is that everyones' efforts are present
> in the design. The current event code looks nothing like what i, or
> someone else, might personally come up with (it has elements of all our
> efforts) - but it is much stronger i think because we worked together
> until we had really resolved the issues...
>
> Does anyone else have any opinions of folder structure? People like
> Alex's structure more. Ok, no problem.. My bigger fear is that we're not
> considering some of the details of these decisions more carefully.
> Everyone fought like hell over the event code. Is there no discussion on
> what impact folder structure will have down the line? I hope its clear
> my concern lately has nothing to do with folder structure, but with
> group dynamic / decision making.
>
> Now that the code is committed, I hope that having a repository does not
> destroy our group process of unanimous consent - especially when it
> comes to core decisions. Certainly, when we get into systems people can
> work more individually. But obviously we cannot have team members
> committing major changes to memory_pools for example, in such a way that
> it is incompatible with another person's development in a specific
> system. Someone says: "Oh yeah. I just implemented some majorly awesome
> improvements to the memory_pool. It's soo much better than the previous
> stuff.".. And we all say, yay! But the result is, due to their design
> (not just a bug), it causes major crashes with another (sub)system in
> development. In this example, the guy working on memory_pools (or folder
> structure) should get unanymous consent from the group before
> committing, right? But on what? Definitely interface (API), probably not
> specific details of implementation (if its buggy, he/she should fix it),
> but how about overall implementation design for the new core thingy (ie.
> structures/algorithms)? Now that we have a repository, where will we
> draw the line between what people can commit without consent and what
> people are required to get unanymous approval for? While not immediately
> practical to mint itself, I hope that we can have discussions on these
> kinds of things as well.
>
> Alex has posted at least 3 different possible folder structures over the
> past two weeks (1. branches / trunk, 2. single folders for all code, 3.
> seperate the folders by OS). Does anyone else have an opinions on this?
>
> Rama
>
> PS. Since i love mint so much (the herb anyway), I will be at the
> meeting tomorrow (thesis be damned) : )
>
>
> Alex Norman wrote:
>
> >there is no need for branches/trunk at this point in the game, later on we
> >can
> >always move to that structure [it is simply an "svn mv" call]
> >
> >the linux/osx/windows folders are for os specific code and building stuff
> >(ie
> >make files, visstudio projects, etc)
> >
> >so we'd have something lke this
> >/tdg/svn/mint/
> > core/
> > bin/
> > include/
> > linux/
> > Makefile
> > x-lib b.s.
> > osx/
> > xcode thing.
> > windows/
> > vis studio solution
> > windoze specific typedefs, etc.
> > source/
> > audio/
> > ..same structure as above
> >
> >-Alex
> >
> >On 0, Rama Hoetzlein <rch at umail.ucsb.edu> wrote:
> >
> >
> >>Ok.. I can't resist. If no one else has any opinions on file structure
> >>(hard to believe), i do : )
> >>Do we really need linux / osc / windows folders?
> >>
> >>Won't it be obvious from the makefiles, projects, etc. which files get
> >>included on which platforms? Besides, I don't think there will really be
> >>that many OS-specific files. Why not just put everything in source and
> >>include?
> >>
> >>Alex, can you give us a run-down of the whole file structure you're
> >>considering? Are bin, output, docs, make folders still at a higher level
> >>than whats shown below? I mean, is it like this?
> >>/tdg/svn/mint/bin
> >>/tdg/svn/mint/core/... (stuff below)
> >>/tdg/svn/mint/output/
> >>
> >>Or did you have something else in mind? Also, i don't see branch / trunk
> >>(this is necessary for svn isn't it, maybe not). (PS. If it was taken
> >>out, cool : )
> >>Was there a discussion about this? Is that between /mint and /core?
> >>
> >>Rama
> >>
> >>
> >>Alex Norman wrote:
> >>
> >>
> >>
> >>>Yo, sorry I'm really busy right now, I wanted to get some sort of
> >>>response about
> >>>the project file organization,, I'd like it to be like this:
> >>>
> >>>/tdg/svn/mint/
> >>> core/
> >>> source/
> >>> all cross-platform shit...
> >>> include/
> >>> all cross-platform shit...
> >>> linux/
> >>> linux specific h/cpp and build [organized however I
> >>> see fit]
> >>> osx/
> >>> osx specifc h/cpp and build [organized however you
> >>> see if]
> >>> windows/
> >>> windows specifc h/cpp and build [organized however
> >>> rama wants it]
> >>>
> >>> audio/
> >>> source/
> >>> include/
> >>> ...
> >>>
> >>> doc/
> >>>
> >>>I figure it is simple, it separates the things that should be separated,
> >>>and we
> >>>can always move shit around later
> >>>-Alex
> >>>
> >>>On 0, Wesley Smith <wesley.hoke at gmail.com> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>in the igert trailer.
> >>>>
> >>>>wes
> >>>>_______________________________________________
> >>>>Tdg mailing list
> >>>>Tdg at mat.ucsb.edu
> >>>>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg
> >>>>
> >>>>
> >>>>
> >>>>
> >>>_______________________________________________
> >>>Tdg mailing list
> >>>Tdg at mat.ucsb.edu
> >>>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg
> >>>
> >>>
> >>>
> >>>
> >>_______________________________________________
> >>Tdg mailing list
> >>Tdg at mat.ucsb.edu
> >>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg
> >>
> >>
> >_______________________________________________
> >Tdg mailing list
> >Tdg at mat.ucsb.edu
> >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg
> >
> >
>
> _______________________________________________
> Tdg mailing list
> Tdg at mat.ucsb.edu
> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg
More information about the Tdg
mailing list