From: H. H. <hen...@gm...> - 2008-08-23 19:44:46
|
Hello, I am now fully working on the GLM test suite and I am using CUnit for it. We will need to think on the build system which we will be using. Somebody mentioned CMake? I don't know about this system much or other systems, so I will lead this up to you completely. I wish someone else would take this to his/her responsibility. Choosing and implementing the build system would easy my work as for now I need to manually run the gcc commands from the terminal every time when I need to compile something. -- Henri 'henux' Häkkinen |
From: Jason M. <ko...@gm...> - 2008-08-23 19:54:34
|
Henri Häkkinen wrote: > Hello, > > I am now fully working on the GLM test suite and I am using CUnit for > it. We will need to think on the build system which we will be using. > Somebody mentioned CMake? I don't know about this system much or other > systems, so I will lead this up to you completely. I wish someone else > would take this to his/her responsibility. Choosing and implementing > the build system would easy my work as for now I need to manually run > the gcc commands from the terminal every time when I need to compile > something. > > -- > Henri 'henux' Häkkinen CMake would be a good choice, since it is fairly easy to use. Though it is problematic in that it requires an additional external download, which is something we should try to minimize. As for you own work, can't you just use a Makefile or something in the interim? I mean, we're still pretty far away from having an initial release, so you should use whatever build process you feel comfortable with. |
From: H. H. <hen...@gm...> - 2008-08-23 19:59:19
|
Yes okay, I can work with Makefile for now. I will not however commit that into the repos, only use it locally. On Sat, Aug 23, 2008 at 10:54 PM, Jason McKesson <ko...@gm...> wrote: > Henri Häkkinen wrote: > > Hello, > > > > I am now fully working on the GLM test suite and I am using CUnit for > > it. We will need to think on the build system which we will be using. > > Somebody mentioned CMake? I don't know about this system much or other > > systems, so I will lead this up to you completely. I wish someone else > > would take this to his/her responsibility. Choosing and implementing > > the build system would easy my work as for now I need to manually run > > the gcc commands from the terminal every time when I need to compile > > something. > > > > -- > > Henri 'henux' Häkkinen > CMake would be a good choice, since it is fairly easy to use. Though it > is problematic in that it requires an additional external download, > which is something we should try to minimize. > > As for you own work, can't you just use a Makefile or something in the > interim? I mean, we're still pretty far away from having an initial > release, so you should use whatever build process you feel comfortable > with. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Glsdk-devel mailing list > Gls...@li... > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > -- Henri 'henux' Häkkinen |
From: H. H. <hen...@gm...> - 2008-08-23 20:08:58
|
Should we adopt the GNU convention of ChangeLog files? Should we keep ChangeLogs per subproject or one ChangeLog for the whole SDK or perhaps both? And where would the per subproject ChangeLogs go? I think a good idea is to keep per subproject ChangeLogs. And we should make a doc/ directory under the main GLSDK/ dir for subproject specific files. GLM ChangeLog would therefore go to GLSDK/doc/glm/ChangeLog. What do you think? BTW, I have adopted a convention to put subproject test suites into test/ directory. You can find the sources for GLM test suite at GLSDK/test/glm. On Sat, Aug 23, 2008 at 10:59 PM, Henri Häkkinen <hen...@gm...> wrote: > Yes okay, I can work with Makefile for now. I will not however commit that > into the repos, only use it locally. > > > On Sat, Aug 23, 2008 at 10:54 PM, Jason McKesson <ko...@gm...>wrote: > >> Henri Häkkinen wrote: >> > Hello, >> > >> > I am now fully working on the GLM test suite and I am using CUnit for >> > it. We will need to think on the build system which we will be using. >> > Somebody mentioned CMake? I don't know about this system much or other >> > systems, so I will lead this up to you completely. I wish someone else >> > would take this to his/her responsibility. Choosing and implementing >> > the build system would easy my work as for now I need to manually run >> > the gcc commands from the terminal every time when I need to compile >> > something. >> > >> > -- >> > Henri 'henux' Häkkinen >> CMake would be a good choice, since it is fairly easy to use. Though it >> is problematic in that it requires an additional external download, >> which is something we should try to minimize. >> >> As for you own work, can't you just use a Makefile or something in the >> interim? I mean, we're still pretty far away from having an initial >> release, so you should use whatever build process you feel comfortable >> with. >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Glsdk-devel mailing list >> Gls...@li... >> https://lists.sourceforge.net/lists/listinfo/glsdk-devel >> > > > > -- > Henri 'henux' Häkkinen > > -- Henri 'henux' Häkkinen |
From: Jason M. <ko...@gm...> - 2008-08-23 20:15:54
|
Henri Häkkinen wrote: > Should we adopt the GNU convention of ChangeLog files? Should we keep > ChangeLogs per subproject or one ChangeLog for the whole SDK or > perhaps both? And where would the per subproject ChangeLogs go? > > I think a good idea is to keep per subproject ChangeLogs. And we > should make a doc/ directory under the main GLSDK/ dir for subproject > specific files. GLM ChangeLog would therefore go to > GLSDK/doc/glm/ChangeLog. > > What do you think? > > BTW, I have adopted a convention to put subproject test suites into > test/ directory. You can find the sources for GLM test suite at > GLSDK/test/glm. Actually, at work we have certain conventions in terms of what commit messages we use. So, if you're working on animation code, you use "CODE_ANIM", if you're checking in animation work, you use "ANIM", and so forth. If we simply define a set of conventions that we consistently use, we should be able to build a change log for a sub-project directly from the SVN commit messages. |
From: H. H. <hen...@gm...> - 2008-08-23 20:24:33
|
That is a good idea too. I have made only one commit which had the message "added glm test suite". I propose we should use the subproject name enclosed in square brackets at the beginning of the message. So for GLM I would use [GLM] or [glm]. Also we should decide on the format of the commit messages. Should we use complete sentences? How comprehensive messages do we need to use? Do we list each files which are modified and every modification done (the GNU convention)? On Sat, Aug 23, 2008 at 11:16 PM, Jason McKesson <ko...@gm...> wrote: > Actually, at work we have certain conventions in terms of what commit > messages we use. So, if you're working on animation code, you use > "CODE_ANIM", if you're checking in animation work, you use "ANIM", and > so forth. If we simply define a set of conventions that we consistently > use, we should be able to build a change log for a sub-project directly > from the SVN commit messages. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Glsdk-devel mailing list > Gls...@li... > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > -- Henri 'henux' Häkkinen |
From: Jason M. <ko...@gm...> - 2008-08-23 20:34:43
|
Henri Häkkinen wrote: > That is a good idea too. I have made only one commit which had the > message "added glm test suite". > > I propose we should use the subproject name enclosed in square > brackets at the beginning of the message. So for GLM I would use [GLM] > or [glm]. Also we should decide on the format of the commit messages. > Should we use complete sentences? How comprehensive messages do we > need to use? Do we list each files which are modified and every > modification done (the GNU convention)? > > > On Sat, Aug 23, 2008 at 11:16 PM, Jason McKesson <ko...@gm... > <mailto:ko...@gm...>> wrote: > > Actually, at work we have certain conventions in terms of what commit > messages we use. So, if you're working on animation code, you use > "CODE_ANIM", if you're checking in animation work, you use "ANIM", and > so forth. If we simply define a set of conventions that we > consistently > use, we should be able to build a change log for a sub-project > directly > from the SVN commit messages. > > > > > -- > Henri 'henux' Häkkinen > We should not list the files that were modified: SVN changelists can already tell you what files were modified. And the description should be sufficient to tell you what those modifications entailed. If any more detailed information is necessary, a quick trip to SVN-diff can tell you anything more. Taking time to detail every file's revision is highly unnecessary. As for the particular convention, brackets are probably a good idea, since they allow a tool to be faster at detecting which modules were changed. |