Re: [Golly-test] new directory structure for repository?

[Tom R. <ro...@gm...>]

Oh yeah, one final reason to ensure we put all binaries in the
same place---we don't want to force people to add more than
one directory to their path for Golly.

On Sat, Jun 30, 2012 at 10:22 AM, Tom Rokicki <ro...@gm...> wrote:

> Okay, I have my comments on the dir structure.
>
>
>> golly/
>>
>>   build/
>>      this is where the Golly executable would be created
>>      Help/          (no change to contents)
>>      Patterns/      (ditto)
>>      Rules/         (ditto)
>>      Scripts/       (ditto)
>>
>
> I understand your objective here, but I don't like having
> Help/Patterns/Rules/Scripts in build.  They belong in the
> top level or in src.
>
> I would do this:
>
> src/ C++ src, build tools, etc.
> Help/
> Patterns/
> Rules/
> Scripts/
> build/ -- empty initially; all obj/exe's go here; any
>    temp files go here; can be deleted anytime
> bin/ -- make install should put *all* binaries here
>
> Please don't separate bgolly from Golly; you
> might think Golly isn't commandline but I often
> (usually?) invoke it as such . . .
>
> Ideally we can even have build32 and build64 if
> someone wants to build both from the same
> source tree at the same time in the same
> directory structure (only one will be "installed"
> at a time though).
>
>   gollybase/
>>   gui-android/
>>   gui-ios/
>>   gui-wx/
>>
>
> Now *this* I really like.  Even further; gollybase
> should permit the build of bgolly with just that.
>
>
>> - Not entirely sure about the need for a build/ directory, but
>> I definitely want the Golly executable to be created in the
>> same location as Help/, Patterns/, Rules/, Scripts/.  That avoids
>> the need to do any bulk copying (as we currently do in Ready).
>>
>
> This makes sense; normal convention is to have a build
> "working" directory that gets objects and exes and is initially
> empty, and have make install copy the build deliverables
> to a bin directory.  (Yes, this puts the executable files one
> level below Help/docs/etc., but it's pretty conventional.)
>
> The other option is to not have a bin directory and just "install"
> into the top level dir.
>
>
>> - Note local-win-template.mk.  Better if people were required to
>> rename this to local-win.mk and make any desired changes to that.
>>
>> Nice.  Can we/should we extend this for Mac/Unix as well?
> People often tweak paths . . . I usually follow the make
> convention of copying the main Makefile (or Makefile-win or
> whatnot) to my own personal makefile (which gets priority on
> systems with case-sensitive filesystems) and make minor or
> temporary edits (compile flags?) there.
>
> -tom
>



-- 
--  http://cube20.org/  --  http://golly.sf.net/  --