two patches...
Ryan C. Gordon
Eric just pointed me to this project, so I figured I should grok
Google Groups and Mercurial as quickly as possible. I probably did
both incorrectly. :)
Here are two simple patches. The first just fixes a C++ scope error
that was preventing compile (mismerge from cmake.org?), and the other
fixes the build to work on Linux...Lua needs libm, since it uses
pow(), etc, but I also enabled the Linux and Mac OS X defines, so Lua
can load shared libraries at runtime (arguably useful?), etc.
http://treefort.icculus.org/cmakelua/cmakelua-patched-to-compile.diff
http://treefort.icculus.org/cmakelua/cmakelua-linux-build.diff
--ryan.
E. Wing
Thanks for the patches. Welcome to the group!
I just checked in your patches into the mainline repository.
A couple of notes for future reference:
Mercurial is a distributed SCM. If you are new to distributed SCMs,
typically, they leverage the built in tools to merge changes (via
pulling and pushing) so things like patch are unnecessary and
obsolete. (I suck at patch so this is a big win for me.) I remember
you asked a few years ago at WWDC what Linus was doing after the
Bitkeeper fallout. It turns out he wrote a very good distributed SCM
called Git that everybody could use. (I was wrong and didn't think he
was writing something the masses could use.) Mercurial is another very
good distributed SCM created by another Linux guy (Matt MacKall) after
the Bitkeeper fallout too. It is written in mostly Python so it
happens to be slightly more portable that Git at the moment.
So with a distributed SCM, typically if you have a change, you publish
a repository with the change. This can be through a webserver
(Mercurial has a built-in webserver), email, ftp, etc. Assembla is
offering free Mercurial hosting, so we just have been creating public
sandboxes as needed. After your repo becomes accessible, I can pull
your changes into my repo and have the tools automatically merge. This
is especially great if my repo has drifted from yours due to other
changes. Generally the tools can resolve the differences. If not and I
get a merge conflict, I can either hand-merge or just rollback and
tell you to pull from my repo and let you handle the merging since you
know your own patch better. Then I can pull from you again after
you're ready.
Alternatively (or also), I can give you write access to the main
repository (and any sandboxes if you desire, though it is easy to
create your own). Just create a user at Assembla and tell me your user
name and I'll give you write access to the repo so you can directly
push changes in. (We're a small group and I know who you are.)
Thanks,
Eric
Peter Drahoš
On 14Mar, 2008, at 6:53, Ryan C. Gordon wrote:
>
> Eric just pointed me to this project, so I figured I should grok
> Google Groups and Mercurial as quickly as possible. I probably did
> both incorrectly. :)
>
> Here are two simple patches. The first just fixes a C++ scope error
> that was preventing compile (mismerge from cmake.org?), and the other
> fixes the build to work on Linux...Lua needs libm, since it uses
> pow(), etc, but I also enabled the Linux and Mac OS X defines, so Lua
> can load shared libraries at runtime (arguably useful?), etc.
Well, i already fixed the lua building issue in my sandbox. The
LuaDist project I'm working on builds Lua using cmake and has the
process tweaked and tested so those interested can look it up here:
http://luadist.svn.sourceforge.net/viewvc/*checkout*/luadist/lua/CMakeLists.txt
The find stuff is optional but by default the Lua makefile links in
readline on linux too. Note that luac needs static library. I wanted
to commit it with my "cmake as lua module" experiments but it seems I
do that separately today.
pd.
Ryan C. Gordon
> Alternatively (or also), I can give you write access to the main
> repository (and any sandboxes if you desire, though it is easy to
> create your own). Just create a user at Assembla and tell me your user
> name and I'll give you write access to the repo so you can directly
> push changes in. (We're a small group and I know who you are.)
http://hg.icculus.org/icculus/CMakeLua/
...so to make sure I have this right:
That's my personal public repo, which is a clone of your repo on
assembla.com. I've cloned my repo to my office's workstation, where I
make changes behind a firewall on my LAN. I "commit" the changes to my
office workstation as I work, "push" all changes as a group to the
hg.icculus.org repo when I am ready to publish them to the world, and
then you pick up the changes you like by "pulling" them from the
hg.icculus.org repo to the assembla.com one...and vice-versa when I
pull your updates into my repos.
I _think_ that's how this works. :)
--ryan.
Ryan C. Gordon
> I _think_ that's how this works. :)
script working again, so you can now build CMakeLua without an
existing CMake binary...and theoretically convert CMake's build
scripts to Lua, too.
How does one announce changes? Just say "go pull the tip of my repo,"
which sounds vaguely naughty, or point to the specific details?
...which are here... http://hg.icculus.org/icculus/CMakeLua/rev/9387731bdf1f
--ryan.
E. Wing
>
>
> > Alternatively (or also), I can give you write access to the main
> > repository (and any sandboxes if you desire, though it is easy to
> > create your own). Just create a user at Assembla and tell me your user
> > name and I'll give you write access to the repo so you can directly
> > push changes in. (We're a small group and I know who you are.)
>
> I'll go one better:
>
> http://hg.icculus.org/icculus/CMakeLua/
Very nice :) By the way, you are still welcome to have write access to
the mainline repository. So if you feel a change is good enough to be
committed to mainline, you don't have to wait for one of us to push
it.
>
> ...so to make sure I have this right:
>
> That's my personal public repo, which is a clone of your repo on
> assembla.com. I've cloned my repo to my office's workstation, where I
> make changes behind a firewall on my LAN. I "commit" the changes to my
> office workstation as I work, "push" all changes as a group to the
> hg.icculus.org repo when I am ready to publish them to the world, and
> then you pick up the changes you like by "pulling" them from the
> hg.icculus.org repo to the assembla.com one...and vice-versa when I
> pull your updates into my repos.
>
> I _think_ that's how this works. :)
>
Sounds like you got it right :)
To be pedantic, we will probably be pulling from your public
hg.icculus.org to our private/local repos first. And then later push
to the assembla.com repo when everything is good. Not having direct
login access to the Assembla repo means we can only push, pull, and
clone from it.
Thanks,
Eric
E. Wing
>
>
> > I _think_ that's how this works. :)
>
> ...and to test that theory, the tip of my repo has the "bootstrap"
> script working again, so you can now build CMakeLua without an
> existing CMake binary...and theoretically convert CMake's build
> scripts to Lua, too.
>
It looks good. I did another Tailor/CVS resync against the official
Kitware CVS. There were more merge conflicts I had to resolve with our
branch. I hope I resolved them okay. I just checked those into our
CMakeLua mainline. So next time you pull from mainline, it should
merge with the current Tailor/CVS that I merged in.
And then I just pulled from your repo to get your bootstrap fixes. No
problems with the merge. I just checked those into mainline too.
And very nice patch. Thanks for that. That was a lot better than trying to put:
#if defined(CMAKE_BUILD_WITH_CMAKE)
// some lua stuff
#endif
everywhere in the code (yuck).
> How does one announce changes? Just say "go pull the tip of my repo,"
> which sounds vaguely naughty, or point to the specific details?
>
> ...which are here...
> http://hg.icculus.org/icculus/CMakeLua/rev/9387731bdf1f
>
We don't have any policies in place for alerts. We've just been
announcing to the mailing list. If you have any better ideas, feel
free to pitch them. The icculus/hg information you setup is a lot more
informative that what we see at Assembla.
Finally, if you are feeling really ambitious, since you have your own
server, maybe you would be interested in hosting and automating the
Tailor/CVS bridge and automating the merge into the CMakeLua mainline.
I've documented the process (which I currently do manually) here:
http://www.assembla.com/wiki/show/CMakeLua/Tailor_CVS-to-Mercurial_Bridge_Repository
Thanks,
Eric
Ryan C. Gordon
> Finally, if you are feeling really ambitious, since you have your own
> server, maybe you would be interested in hosting and automating the
> Tailor/CVS bridge and automating the merge into the CMakeLua mainline.
I thought I might take a quick look at why the Visual Studio
generators broke next.
--ryan.
Peter Kümmel
>
> Eric just pointed me to this project, so I figured I should grok
> Google Groups and Mercurial as quickly as possible. I probably did
> both incorrectly. :)
>
> Here are two simple patches. The first just fixes a C++ scope error
> that was preventing compile (mismerge from cmake.org?), and the other
> fixes the build to work on Linux...Lua needs libm, since it uses
> pow(), etc, but I also enabled the Linux and Mac OS X defines, so Lua
> can load shared libraries at runtime (arguably useful?), etc.
>
> http://treefort.icculus.org/cmakelua/cmakelua-patched-to-compile.diff
The code in cvs was(?) also broken.
> http://treefort.icculus.org/cmakelua/cmakelua-linux-build.diff
>
> --ryan.
>
>
>
> >
--
Peter Kümmel