source code layout and organization

[Stephen Woodbridge]

Steve Lime wrote:
> Typically one runs configure from the top level directory so
> Makefile.in, configure.in and so on should probably live there along
> with the high level docs. I don't know where it makes sense to create
> lib and bin directories. Creating in svn simplifies the Makefile a
> bit.
> 
> I like the idea myself but don't sense a lot of interest from
> others...

This makes sense from the point of view of mapserver as a library if we 
might be interested in the C api. As I have mentioned in the past, I 
think having a C api would be a good thing. We have a C# api via 
mapscript. I'm just saying that if we had a stable C api that it might 
get used. I know I would use it because it makes installation of 
applications much easier and I think more portable than trying to build 
and install all the variants of apache, php, perl, mapscript, mapserver etc.

-Steve W

> Steve
> 
>>>> "Kralidis,Tom [Burlington]" <Tom.Kralidis at EC.GC.CA> 05/29/07
>>>> 1:21 PM >>>
> How about:
> 
> mapserver bin/ (the output binaries) lib/ (libmap.a, anything else?) 
> src/ mapscript/ tests/
> 
> - I'm guesssing bin/ and lib/ would not be part of the svn, rather 
> created when building?
> 
> - could README and INSTALL live in the root, and config files, etc.
> live in src/?
> 
> ..Tom
> 
> 
>>> mapserver/ etc/ core/ formats/ mapscript/ ogc/ tests/ util/
> 
> 
>> I'd be very interested in code cleanup, but like Frank stuffing
>> things into directories doesn't seem that beneficial. I guarantee
>> there are grey areas, for example, where do you put something like
>> mapgml.c, ogc or formats?
>> 
>> I'd be more interested in a structure like:
>> 
>> mapserver/ lib/ bin/ include/  (?) src/ tests/ mapscript/
>> 
>> So at least after a build the binaries are separated from the 
>> source code. All the configuration files, READMEs and HISTORY.txt
>> would live in the top level directory.
>> 
>> As for code clean-up, besides those already mentioned. 1) The msObj
>> definition is a mess in maptemplate.h (I think I created a bug for
>> that already) and 2)  mapimagemap.c has a lot of leftovers from
>> it's original coding.
>> 
>> Steve
>> 
>>>>> On 5/29/2007 at 8:14 AM, in message
>> <2576812186CDD411BF1500508B6DCE9511B30E9D at ecnwri1.ontario.int. 
>> ec.gc.ca>, "Kralidis,Tom [Burlington]" <Tom.Kralidis at EC.GC.CA>
>> wrote:
>>> Hi,
>>> 
>>> Does anyone have comments w.r.t. the organization of the
>> codebase into
>>> something more palatable?  For example:
>>> 
>>> mapserver/ etc/ core/ formats/ mapscript/ ogc/ tests/ util/
>>> 
>>> This would be much easier now that MapServer is svn'd.
>>> 
>>> This would also provide the opportunity to do a once over against
>>>  files in the codebase (i.e. mapprojhack.c might deserve a more 
>>> appropriate filename, or using mapmygis.c when MapServer
>> can use OGR
>>> for VRT style and spatial connections).
>>> 
>>> Any comments?
>>> 
>>> ..Tom