http://www.oreilly.com/pub/a/mac/2005/04/22/eclipse.html is a good article that shows how to take a simple xCode app and then use Eclipse to build it.

They seem to think that Eclipse is just for Java. It can also be used for PHP, Perl, C/C++ and Ruby. Eclipse is an IDE on top of the platform.

Doing this before you get frustrated really helps:
ppm repo add theory58S
That adds updated and sometimes otherwise unknown packages to the possible packages you can run.

Another item is if you just run ppm you get the GUI interface, that doesn't lead to what really needs to get done. CLI is the way to go.

http://www.libgd.org/DOC_INSTALL_OSX is a good page on all the steps one needs to get GD installed for perl. Is it worth it? Time will tell.

Well, I am real late for work now. It turns out my Mac did not have automake-1.9.6, which caused all sorts of issues. I got that from here: http://ftp.gnu.org/gnu/automake/ more specifically here: http://ftp.gnu.org/gnu/automake/automake-1.9.6.tar.gz

Once I installed that, I got GD to make. Not pretty. Not pretty at all!

Bugzilla is written in perl. It can be downloaded here http://www.bugzilla.org/download/

You need to have a web server. I personally like MAMP.

As mentioned it is in perl. So, when you run 'checksetup.pl' you will get a list of things you need to install. You install these things with CPAN, today I found a way to always be running 'sudo make' instead of just make. If you ain't sudo, you ain't going to be happy.

at shell prompt:
sudo cpan
then you enter:

o conf make_install_make_command 'sudo make'
o conf commit
q

That should help!
These are the things I need to install!

GDGraph: /usr/bin/perl -MCPAN -e 'install "GD::Graph"'
GDTextUtil: /usr/bin/perl -MCPAN -e 'install "GD::Text"'
Template-GD: /usr/bin/perl -MCPAN -e 'install "Template::Plugin::GD::Image"'
GD: /usr/bin/perl -MCPAN -e 'install "GD"'
Email-Reply: /usr/bin/perl -MCPAN -e 'install "Email::Reply"'

http://www.campwoodsw.com/ says
"The freeware program SourceMonitor lets you see inside your software source code to find out how much code you have and to identify the relative complexity of your modules. For example, you can use SourceMonitor to identify the code that is most likely to contain defects and thus warrants formal review. SourceMonitor, written in C++, runs through your code at high speed. SourceMonitor provides the following:

* Collects metrics in a fast, single pass through source files.
* Measures metrics for source code written in C++, C, C#, VB.NET, Java, Delphi, Visual Basic (VB6) or HTML.
* Saves metrics in checkpoints for comparison during software development projects.
* Displays and prints metrics in tables and charts.
* Operates within a standard Windows GUI or inside your scripts using XML command files.
* Exports metrics to XML or CSV files for further processing with other tools."

Hello,

If you set $P4VFOLDER to where you installed the p4v.real file, this should work in a bash shell:

perl -e '$p4CLI=exec "p4 -V"; ' | grep -G "^Rev." | echo "P4CLI="`awk '{ print $2 }'`
perl -e '$p4D=exec "p4d -V"; ' | grep -G "^Rev." | echo "P4D="`awk '{ print $2 }'`
$P4VFOLDER/p4v.real -V | grep -G "^Rev." | echo "P4V="`sed 's/.*Client\///'`

This will result in:
P4CLI=P4/MACOSX104X86/2007.3/143793
P4D=P4D/DARWIN80X86/2007.3/152469
P4V=MACOSX104X86/2007.3/151553
or the like.

Notice the different method to get p4v's revision. Did you know the p4v.real can be run from the command line while p4v can not?

http://richardsbraindump.blogspot.com/ has a good amount of information on Microsoft Team Foundation Server. Such as this: http://richardsbraindump.blogspot.com/2007/07/versioning-builds-with-tfs...

What I found interesting is not installing Developer Studio on the build machine. Just using the .Net framework msbuild. That is cool.

While I did not know how, I knew I could make a DMG. Now to find a better way than this manual process: http://www.wikihow.com/Make-a-DMG-File-on-a-Mac

On Mac and Unix command line clients, you know, or learn shortly, that you can't "export" system variables from a script. But if you work on several projects, you will soon get tired of exporting various P4 required variables.

You can use the P4CONFIG to group several of these P4 variables together. But you still have to type
export P4CONFIG=<SOMEFILE>

Here is a more structured way....

If you do this below when it returns, you won't have any more aliases then when you started. Unless you put it in your .profile file!

export P4CONFDIR=~/p4config
# This sets aliases for P4
for P4C in `find $P4CONFDIR -type f`
do
alias p4c`basename -s .P4CONFIG $P4C`='export P4CONFIG='$P4C
done
# End of setting aliases for P4.

Now, what does this do? Well if for each P4 client you have you create a "client.P4CONFIG" file in the $P4CONFDIR, you can create a simple alias to change to your different clients.

Like the maid that doesn't do windows, clean targets get rid of most files you built from source. The get rid of most of them. The reason is most build scripts don't force us to put the resulting artifacts out side of the source-related folders.

A true clean should delete itself as it deletes the folder and re-create the source-related folders with the need to rely on "magic" lines like "rm *.o"

http://www.cmcrossroads.com/content/view/10378/120/ is what made me think of that.