[epiar-devel] GNU Autotools Walkthrough

Moss Jones bmossjon at yahoo.com
Mon Nov 2 18:12:29 PST 2009 

Alright.  Still figuring out the github.com so will be a bit, but I 
can also post the bugs for the FYI.  Looking at possibly 
posting a KDevelop.  Anyone know how to use the
.gitignore file?



----- Original Message ----
From: Matthew Zweig <thezweig at gmail.com>
To: epiar-devel at epiar.net
Sent: Mon, November 2, 2009 5:52:38 PM
Subject: Re: [epiar-devel] GNU Autotools Walkthrough

Yeah, definitely my fault.  Is this the only instance of this  
mistake?  I had no idea that Mac OS X was  case-insensitive like  
this.  This is a one line fix for me, but I think since you found it,  
you should commit it to your git fork and I'll pull it in and merge it  
into the Master.  It's a trivial change, and a great opportunity to  
figure out how github works (for both of us, I'm definitely still  
figuring it out).

Good Catch,
~Matt (knowknowledge)

On Nov 2, 2009, at 3:28 PM, Christopher Thielen wrote:

> Looks like Matt's fault to me. :)
>
> It's not strictly in our CodingConventions doc on Trac yet but we do
> respect case-sensitive file systems. I believe most of the code does,
> so you'll have to fix those in the meantime and submit them back to
> Matt, who's maintaining the git side of things.
>
> On Nov 2, 2009, at 3:26 PM, Moss Jones wrote:
>
>> Sounds good.  So it's basically first come first serve then.
>> One thing I did notice on the code at github.com is that
>> a lot of filenames have changed towards case
>> sensitivity.
>>
>> .../Utilities/lua.cpp:10:31: error: Engine/Simulation.h: No such
>> file or
>> directory
>>
>> which has been named actually to "simulation.h"
>>                                                   ^
>>
>> Not sure if anyone got this yet, but I'm Linux and filenames
>> are case sensitive for me on this machine.  Windows
>> won't report this and some Linux versions that I know of,
>> but most Linux systems will.
>>
>> -- Moss
>>
>>
>>
>>
>>
>> ----- Original Message ----
>> From: Christopher Thielen <cthielen at mac.com>
>> To: epiar-devel at epiar.net
>> Sent: Mon, November 2, 2009 5:16:49 PM
>> Subject: Re: [epiar-devel] GNU Autotools Walkthrough
>>
>> Good idea, but I think this is better done using the Trac
>> functionality at epiar.net/trac . We'll need to get you a Trac
>> account. It is there to handle Wiki needs, the tracking of bugs,  
>> and I
>> believe there are even user pages, or in the very least we can add
>> user pages, to show what everybody else is up to.
>>
>> Basically, we establish milestones (e.g. version 0.1.0), and that
>> milestone is made up of a collection of bugs, which aren't  
>> necessarily
>> bugs per se, but can be features, e.g. "We need the ability to blast
>> asteroids!". Those bugs are then assigned to individuals, so people
>> know who's holding up the release and can make fun of them, etc. :)
>>
>> On Nov 2, 2009, at 3:03 PM, Moss Jones wrote:
>>
>>> Along with this Chris, it would also be nice to have a directory
>>> for the updates from each user.  Either a directory with each
>>> file name as UpdatesMoss.txt or a sub-directory named like
>>> Moss.  Then we can check on everyone's progress to get
>>> an idea of what to work on.
>>>
>>> I love modularization myself so not to be pushy or anything
>>> but if things get mis-sorted, they never tend to get done.
>>>
>>> -- Moss
>>>
>>>
>>>
>>> ----- Original Message ----
>>> From: Christopher Thielen <cthielen at mac.com>
>>> To: epiar-devel at epiar.net
>>> Sent: Mon, November 2, 2009 4:38:38 PM
>>> Subject: Re: [epiar-devel] GNU Autotools Walkthrough
>>>
>>> I should mention that at least in GNU glibc (a huge and important  
>>> GNU
>>> project), they have a preference toward keeping their source code  
>>> and
>>> object files separate (so you can keep pulling from the tree while
>>> maintaining your own separate object files or something) and they
>>> also
>>> use GNU autotools. They do it in a manner like this:
>>>
>>> svn co project
>>> ls project # project is a child of current directory
>>> mkdir build
>>> cd build
>>> ../project/configure
>>>
>>> That way, build/ has all the object files while project/ (a
>>> completely
>>> different child dir at the same level as project) is kept "clean".
>>>
>>> On Nov 2, 2009, at 2:28 PM, Moss Jones wrote:
>>>
>>>> I agree with that and noticed that too.  We should have a build,
>>>> bin, docs
>>>> directory and so on.  On the 0.5 source, it was declared in the
>>>> Makefiles (i.e. Makefile.linux).  Now I think there is just the
>>>> Makefile.am
>>>> where you declare OBJS=main.o, sprites.o, etc.  Just place the dir
>>>> name ./objs/ in front of this or declare a variable OBJ_DIR=./objs
>>>> as such.  Still working with github.com and new source codes, so
>>>> posting that info here...
>>>>
>>>>
>>>>
>>>> ----- Original Message ----
>>>> From: Matthew Zweig <thezweig at gmail.com>
>>>> To: "epiar-devel at epiar.net" <epiar-devel at epiar.net>
>>>> Cc: "epiar-devel at epiar.net" <epiar-devel at epiar.net>
>>>> Sent: Mon, November 2, 2009 3:39:53 PM
>>>> Subject: Re: [epiar-devel] GNU Autotools Walkthrough
>>>>
>>>> I spent a few hours this weekend trying to figure out how to have
>>>> the
>>>> *.o files not generated in the project root.  I never found a
>>>> solution
>>>> that I liked.  If it's possible, I would like to get our repo
>>>> cleaned
>>>> up.
>>>>
>>>> ~Matt
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Nov 2, 2009, at 11:53 AM, Christopher Thielen <cthielen at mac.com>
>>>> wrote:
>>>>
>>>>> I saw a decent explanation of the build system we use and I know  
>>>>> it
>>>>> confuses a lot of people so here's the GNU Autotools build system
>>>>> in
>>>>> one page: http://epiar.net/trac/wiki/AutotoolsBuildSystemHowto
>>>>>
>>>>> I took it from reddit.com and it's permanently hosted on our Trac
>>>>> system
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> epiar-devel mailing list
>>>>> epiar-devel at epiar.net
>>>>> http://epiar.net/mailman/listinfo/epiar-devel
>>>> _______________________________________________
>>>> epiar-devel mailing list
>>>> epiar-devel at epiar.net
>>>> http://epiar.net/mailman/listinfo/epiar-devel
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> epiar-devel mailing list
>>>> epiar-devel at epiar.net
>>>> http://epiar.net/mailman/listinfo/epiar-devel
>>>
>>> _______________________________________________
>>> epiar-devel mailing list
>>> epiar-devel at epiar.net
>>> http://epiar.net/mailman/listinfo/epiar-devel
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> epiar-devel mailing list
>>> epiar-devel at epiar.net
>>> http://epiar.net/mailman/listinfo/epiar-devel
>>
>> _______________________________________________
>> epiar-devel mailing list
>> epiar-devel at epiar.net
>> http://epiar.net/mailman/listinfo/epiar-devel
>>
>>
>>
>>
>> _______________________________________________
>> epiar-devel mailing list
>> epiar-devel at epiar.net
>> http://epiar.net/mailman/listinfo/epiar-devel
>
> _______________________________________________
> epiar-devel mailing list
> epiar-devel at epiar.net
> http://epiar.net/mailman/listinfo/epiar-devel

_______________________________________________
epiar-devel mailing list
epiar-devel at epiar.net
http://epiar.net/mailman/listinfo/epiar-devel

More information about the epiar-devel mailing list