[epiar-devel] CMake files

[Matthew Zweig]

No need to create a seperate repository; check out git branches.  I  
suggest that you keep a public branch for cmake like I did for  
'resources'.  In fact the standard hit workflow involves never working  
on the 'master' branch and always working on a branch named after the  
task at hand.

I also think that we should record in the wiki and checked in build  
notes that if a developer cannot use gcc or vs for some reason they  
should check out your cmake branch.  No reason to lose their work or  
yours based off of a disagreement on compiler choice.

Thanks for the work,
~Matt

On Nov 9, 2009, at 10:01 AM, Maoserr <maoserr at gmail.com> wrote:

> Ok, I think I get the picture.  Just to finalize things up, I think  
> here's
> what I"m going to do
> 1) Modify all cmake scripts to run from another directory
> 2) Create a another repository for my cmake files, which I'll maintain
> separately.
>
> Just FYI, I don't think CMake is better than autotools if we're
> restraining ourselves only to GNU compilers, however VS support is a  
> big
> deal for me.  Right now it seems like overkill to use cmake if all  
> we plan
> on support is VS though.
>
> Nonetheless, this has cause more discussion than I thought it would,  
> so I
> think it's best to leave things as it is, and discuss using other  
> build
> tools when/if there's a demand for more compiler support.  I'm  
> getting the
> impression that out of all the developers, we don't use more than GNU
> compiler and VS anyways, so maintaining vs projects and autotools  
> won't be
> a big deal.
>
> On Mon, 09 Nov 2009 12:30:28 -0500, Christopher Thielen <cthielen at mac.com 
> >
> wrote:
>
>> It's something arke and I have been discussing, there's a couple  
>> notes
>> and issues:
>>
>> My concerns/thoughts:
>>
>> * cmake has to be installed to build it. This is not true of  
>> autotools
>> (configure is a regular shell script).
>>
>> * On everything except Windows, people won't know what to do, and  
>> even
>> then, some Windows programmers won't know what to do. This is a big
>> problem. We need to remain accessible if people are going to care.  
>> The
>> fact that the only projects of note that seem to use it are Blender
>> and KDE4 isn't helping (and KDE was never trivial to build in the
>> first place, dozens of logical dependencies aside).
>>
>> * The only advantage to this is making a few minutes a day less work
>> for Visual Studio developers, and those few minutes will rapidly
>> diminish as we start adding fewer new files over time and instead  
>> work
>> on existing code. You have to remember we're early on in the  
>> project's
>> life and having to add this many new files or library dependencies  
>> all
>> the time is unusual, and will get calmer over time. This is a big
>> point for me: every developer would have to learn a non-popular build
>> system for the benefit of a smaller number of people, and that  
>> benefit
>> itself is only moderately-sized, e.g. "What? Linking error with this
>> updated code? Oh, there's a new .cpp file. *60 seconds later* Ok,
>> running."
>>
>> * Windows developers could avoid this problem entirely by using  
>> mingw/
>> msys. I'm not forcing anybody to use it, and I know Visual Studio is
>> quite a bit better, but it's worth pointing out that the use of  
>> Visual
>> Studio is causing this conversation. Maybe that's moot.
>>
>> * Most libraries on Unixes install autotools-compatible macros. Does
>> cmake support these? Otherwise, how will we get our library checks?
>> e.g. SDL comes with an autotools macro so in our configure.ac file,  
>> we
>> simply say "run the SDL macro", which is made by the SDL folks to
>> check for the needed SDL headers and performs linking tests to ensure
>> it will build correctly. This is the same of libxml2 and SDL_image.
>>
>> * Why don't more projects use it? Would we be ahead of our game in
>> using it?
>>
>> All that said, using a cross-compiler build system (that's really  
>> what
>> it is) seems very logical, even though we only support two compilers
>> (it would make a lot more sense if we supported Borland and  
>> Metrowerks
>> and all the rest). It seems to have a few rough edges though.
>>
>> All that said, I have a very volatile opinion on matters such as
>> these, so after we release 0.1.0, I promise to look into cmake and
>> give it a more honest going over. It might be worth switching to
>> anyway, but please give me some time to get 0.1.0 out and then look  
>> at
>> it.
>>
>> On Nov 9, 2009, at 8:46 AM, Maoserr wrote:
>>
>>> that's a fair point.  I haven't learned autotools, and they say the
>>> best
>>> way to determine if something is good is to try it.  However, I will
>>> say
>>> that when I first started writing cross platform programs I looked
>>> at a
>>> lot of discussion regarding SCon vs CMake vs Autotools vs Jam,
>>> etc.  And
>>> the generally discussion seems to imply that SCon or CMake was the
>>> way to
>>> go.  As of right now, I feel CMake is more than powerful enough for
>>> anything I could think of (perhaps the other tools are too).  And I
>>> have
>>> no inclination to learn Autotools, because the lack of support for
>>> generating VC compiler projects/makefiles.  I'm sure they work
>>> perfectly
>>> fine on linux, but as I come from an Windows background, I've always
>>> preferred the VC compilers on windows.  I think it's important to
>>> support
>>> MinGW too, just because it might be more comfortable for others.
>>> And of
>>> course windows has a variety of other compilers (Watcom, DigitalMar,
>>> Borland) that cmake supports. (Unfortunately I don't think all the
>>> thirdparty libraries support those compilers, so Epiar probably  
>>> won't
>>> build on those compilers, I've tried Watcom and Borland and they  
>>> both
>>> failed).
>>>
>>> All the features you have described so far for autotools seem to be
>>> implemented in CMake (Checking for libraries, add dependencies,
>>> check for
>>> system conditions, partial rebuilds).  CMake includes a GUI that
>>> lets the
>>> user change options too (for example, I have the CMake script on
>>> windows
>>> that lets the user choose to either search for prebuilt SDL
>>> libraries or
>>> compile them from source.  If compile from source is chosen, another
>>> option gets added that lets the user choose to automatically
>>> download the
>>> source from the internet and compile it without any manual
>>> intervention.
>>> This isn't implemented in the Linux version as I don't think it's a
>>> good
>>> idea to not use the package manager.)  The user can dynamically
>>> change the
>>> compiler/linker flags and keep those modifications in addition to
>>> what the
>>> developer of the cmake script set as the default.
>>>
>>> The thing i don't like about cmake is that it requires the user to
>>> have
>>> cmake installed for makefiles.  So you can't just generate makefiles
>>> and
>>> distribute it with your package.  On the other hand, VC projects
>>> generated
>>> seem independent and don't rely on cmake.  So anyone who wants to
>>> compile
>>> your package using makefiles cannot do so without the actual cmake
>>> program
>>> installed.  On the otherhand, comparing this to doing all the work  
>>> of
>>> building thirdparty libraries, it might not be such a big deal.
>>>
>>> I don't know, I'd say the best way for you to decide if we should  
>>> use
>>> cmake is just to try it,  I'm certainly no expert on it yet, but I
>>> plan on
>>> keep using it at least for my personal builds.
>>>
>>> To be clear, I realize a lot of the chatter regarding the use of
>>> autotools
>>> are probably coming from novices who just got frustrated learning
>>> it, but
>>> it just doesn't have all the features that I want from a build tool
>>> either, so that's why I don't want to learn it, not because of the
>>> chatter.
>>>
>>> On Mon, 09 Nov 2009 11:18:43 -0500, Christopher Thielen
>>> <cthielen at mac.com
>>>>
>>> wrote:
>>>
> <snip>
>>> <snip>
> <snip>
>>>
>>>
>>> _______________________________________________
>>> 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