[ale] [OT] Any Eclipse and C users on the list

JD jdp at algoloma.com
Sun Feb 3 12:31:26 EST 2013


I've been using a C/C++ makefile that handled dependencies automatically for about 20 yrs.  It uses gmake and something called makedepend(s), if memory serves.  I haven't coded in some time, but it worked across 10+ different platforms for commercial software that the company.  We even switched the MSVC project files to gmake to better control those builds.  

I'll look for it and email you privately.

Michael Potter <michael at potter.name> wrote:

>After a couple of hours googling around to see how others are using
>CMake and automatic dependency checking, I am beginning to think that
>CMake is not the solution to my problem.
>
>I don't want to maintain the dependencies by hand, and I don't want to
>continue to use my kludgy bash script for extracting the dependencies.
>
>Here is what I am currently investigating:
>http://www.gnu.org/software/automake/manual/html_node/Dependency-Tracking.html#Dependency-Tracking
>
>Automake does dependency tracking as it is compiling so I have hope
>that my generated code will not be a problem.   That is in contrast
>with dependency tracking that happens at the start of a compile;
>because the generated code does not exist at the start of a compile,
>the dependencies cannot be determined.
>
>On Fri, Feb 1, 2013 at 12:58 PM, Ryan Curtin <ryan at igglybob.com> wrote:
>> On Fri, Feb 01, 2013 at 10:26:21AM -0500, Michael Potter wrote:
>>> Here is my question that I cannot find documented in CMake...
>>>
>>> Is there a way to generate the dependencies from the source?
>>>
>>> Specifically, if I have source that looks like this:
>>>
>>> in dilbert.c:
>>> #include "src/alice.h"
>>> #include "src/wally.h"
>>>
>>> Right now I have a hand coded bash script that generates
>>> obj/dilbert.o: src/dilbert.c src/alice.h src/wally.h
>>>    cc -o $@ src/dilbert.c
>>>
>>> That way all I need to do is maintain the source and the tedious
>part
>>> of maintaining the makefile is done for me.   The bash script is
>>> sophisticated enough to handle recursion and ignoring some includes.
>>> As slick as it is, I want to get of this system and move to main
>>> stream scheme.
>>>
>>> How does cmake eliminate that part of the makefile creation?
>>
>> In general CMake does not do this.  You can set it up in different
>ways,
>> but the way I generally set up a project is to put either a
>> CMakeFiles.txt in each directory, or one CMakeFiles.txt somewhere,
>and a
>> command like
>>
>> add_executable(the_program
>>   src/alice.h
>>   src/alice.c
>>   src/wally.h
>>   src/wally.c
>>   src/dilbert.c
>>   ...
>> )
>>
>> but this does mean that every file you make in the project, you have
>to
>> add it to the list of compiled files.
>>
>> I think that what you want to do is say something like
>> "add_executable(the_program main.c)" and then CMake looks through all
>> the #includes of main.c (recursively) to generate a list of files to
>be
>> compiled.
>>
>> That is a complex problem and while it can be solved with CMake it
>would
>> be... somewhat backhanded.  You could write a script which would look
>> through each file in a list for #include lines using regexes, and
>then
>> somehow pruned that list to only those #includes which were relevant
>> (i.e. filter out #include <stdio.h> and similar).  Then you could
>call
>> that script again recursively with the new list.
>>
>> There are a few gotchas in that idea, but it sounds like you already
>> have this system basically implemented in bash.  Converting it to a
>> CMake script is within the realm of possibility, if that's what you
>want
>> to do.  I've not seen a CMake project that does this, but if it works
>> and it's well-documented and maintainable, I don't see any problems
>with
>> it.
>>
>> --
>> Ryan Curtin       | "Think!  What to do!"
>> ryan at igglybob.com |   - The Master
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
>
>
>
>-- 
>Michael Potter
>  Tapp Solutions, LLC
>  Replatform Technologies, LLC
>+1 770 815 6142  ** Atlanta ** michael at potter.name  **
>www.linkedin.com/in/michaelpotter
>_______________________________________________
>Ale mailing list
>Ale at ale.org
>http://mail.ale.org/mailman/listinfo/ale
>See JOBS, ANNOUNCE and SCHOOLS lists at
>http://mail.ale.org/mailman/listinfo

-- 
Sent from a Linux system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130203/f1f5df19/attachment-0001.html>


More information about the Ale mailing list