[Tdg] Mint updates
Wesley Smith
wesley.hoke at gmail.com
Wed Mar 7 15:09:31 PST 2007
Well, please excuse my brevity earlier. I was in the middle of class
and couldn't write alot. Anyway, for GLV we setup platform specific
code in a folder with the project for that platform like below. In
general there is usually a config.h with a ton of ifdefs that sets
things like floating point precision and this kind of stuff (from
ode's config.h)
/* Define to 1 if you have the <strings.h> header file. */
#define HAVE_STRINGS_H 1
/* Define to 1 if you have the <string.h> header file. */
#define HAVE_STRING_H 1
/* Define to 1 if you have the <sys/select.h> header file. */
#define HAVE_SYS_SELECT_H 1
/* Define to 1 if you have the <sys/socket.h> header file. */
#define HAVE_SYS_SOCKET_H 1
/* Define to 1 if you have the <sys/stat.h> header file. */
#define HAVE_SYS_STAT_H 1
/* Define to 1 if you have the <sys/time.h> header file. */
#define HAVE_SYS_TIME_H 1
/* Define to 1 if you have the <sys/types.h> header file. */
#define HAVE_SYS_TYPES_H 1
/* Define to 1 if you have the <time.h> header file. */
#define HAVE_TIME_H 1
/* Define to 1 if you have the <unistd.h> header file. */
#define HAVE_UNISTD_H 1
/* Define to 1 if you have the <values.h> header file. */
/* #undef HAVE_VALUES_H */
/* Define to 1 if you have the `vprintf' function. */
#define HAVE_VPRINTF 1
As for the notion that the repository will hurt collaboration, people
not showing up to meetings is worse, especially if you don't tell
people and only 1 person shows up.
/tdg/svn/mint/
core/
bin/
include/
.....
config.h
linux/
Makefile
x-lib b.s.
osx/
carbon-src/
xcode thing.
windows/
win-api-src/
vis studio solution
windoze specific typedefs, etc.
source/
audio/
..same structure as above
On 3/7/07, Rama Hoetzlein <rch at umail.ucsb.edu> wrote:
>
> >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.
> >
> >
> This does not resolve design issues.. It is a tool like any other. It is
> certainly feasable that two people working on core develop seperate
> branches that, because they never discussed design, are incompatible
> with one another. Why should someone go to the effort of developing an
> algorithm/implementation branch only to have it be disapproved from
> merging with the trunk? It seems far better to cut off potential
> disaster through an active design process. I don't think versioning
> software can replace important design decisions.. This is what i've been
> feeling lately. Thats all. I don't want the repository to be an excuse
> not to actively discuss and solve design problems (on any issue)
>
> To give an example with folder structure. Yes, we can obviously move
> stuff around later. But a new folder structure later will not only
> require that we redo all makefiles and projects, but will impact
> workflow also - everyone would need to switch to the new structure. I
> think these discussions are essential to our process.
>
> However, if everyone agrees that we shouldn't worry about it now, then
> that another matter. With the exception of Jorges last e-mail and Wes's
> more general input ("Overall I like Alex's structure best"), its just
> been me and Alex so far on the actual details.
>
> Rama
>
> >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
> >>
> >>
> >_______________________________________________
> >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