mkmakefile

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

mkmakefile

Boost - Dev mailing list

Hi!
is anyone interested in developing this code further?
pls have a look at:

http://www.multi.fi/~ghaga
http://www.multi.fi/~ghaga/mkmakefile/

anyone?
Ty, Greg


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: mkmakefile

Boost - Dev mailing list
Hello,
I am interested.

Thanks.
Abhinav


On Sun, Apr 1, 2018 at 7:40 PM, Ggh via Boost <[hidden email]> wrote:

>
> Hi!
> is anyone interested in developing this code further?
> pls have a look at:
>
> http://www.multi.fi/~ghaga
> http://www.multi.fi/~ghaga/mkmakefile/
>
> anyone?
> Ty, Greg
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman
> /listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: mkmakefile

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, Apr 1, 2018, 9:10 AM Ggh via Boost <[hidden email]> wrote:

>
> Hi!
> is anyone interested in developing this code further?
> pls have a look at:
>
> http://www.multi.fi/~ghaga
> http://www.multi.fi/~ghaga/mkmakefile/
>
> anyone?
>

Why?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: mkmakefile

Boost - Dev mailing list

Quoting Rene Rivera via Boost <[hidden email]>:

> On Sun, Apr 1, 2018, 9:10 AM Ggh via Boost <[hidden email]> wrote:
>
>>
>> Hi!
>> is anyone interested in developing this code further?
>> pls have a look at:
>>
>> http://www.multi.fi/~ghaga
>> http://www.multi.fi/~ghaga/mkmakefile/
>>
>> anyone?
>>
>
> Why?
wondering...if I'm reinventing the wheel ( again as many do)....I  
guess there's loads of similar stuff
Greg
>
> _______________________________________________
> Unsubscribe & other changes:  
> http://lists.boost.org/mailman/listinfo.cgi/boost




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: mkmakefile

Boost - Dev mailing list
On 01-04-18 17:13, Ggh via Boost wrote:
> wondering...if I'm reinventing the wheel ( again as many do)....I
> guess there's loads of similar stuff

Similar to what? Shell scripts that write a makefile?

Also, your link was broken. The fixed link leads to incomplete code (

You  don't state the target implementations (just GNU make? what
versions?), features required, features already supported, etc.

I think what I've seen is trivial. I'm not at all convinced that
cramming the options all on some command line to be parsed by a ...
questionable script is better than writing the equivalent makefile (or
Makefile.am, m4 template or CMakeLists.txt, ... if you intend to
generate the makefile).

The code is... what I'd call bad code. You should probably have posted
it for review instead (https://codereview.stackexchange.com/ e.g.).

It fails to use all the conventions in place to make Makefiles
maintainable. You subvert default variable naming (CC for CXX, really?).

Here's the same program converted to actual C++ - in 306 lines of code
(instead of the incomplete 560 lines):
https://gist.github.com/sehe/57693dedda3de679c33848074d61c8e6/e48398e97f42071e61e2d778cdbacb4f9d0b1750

Now note that *LOTS* of things have been fixed with respect to quoting
of path names, but lots of things still don't work (no way to pass
compiler/linker flags, static libraries aren't built (because the target
rule was wrong), static libraries cannot link (because it needs position
indepent code, but, again, compiler flags cannot be passed), the linker
is always using `g++` instead of `gcc` even if all source files were
compiled with the C compiler etc.

To fix things, I cleaned things up **A LOT** MORE:
https://gist.github.com/sehe/57693dedda3de679c33848074d61c8e6/3f22091fc4f3931ecafd3b51a93f9381ee561e2e

Now the code is 351 lines of code, but actually organized (you could
split headers and implementations here), it has actually working
   
     - STATICLIBTARGET and LIBTARGET
     - much simplified rules
     - dependency detection / creation
     - using OBJS instead of hardcoding names and even `*.o` (ugh)
     - separating discover_sourcefiles, generate_makefile, run_make
     - deduceLinker (instead of using g++ to link C programs...)
     - allow for compiler flags
     - don't repeat includes and libraries with each (intermediate) target

A screenshot of interactively bootstrapping the program using itself:
https://imgur.com/a/AlYRz, using the command line:

./bootstrap/mymakemaker -hd -t mymakemaker -cxxflags -std=c++1z -tt exe
-wd bootstrap -mk -cc 'clang++' -i ~/custom/boost -L
~/custom/boost/stage/lib/ -l boost_program_options -l stdc++fs
Reading directory:    "bootstrap"
Creating makefile:    makefile.mk
Making...
------------------------------------------------------
"clang++"  -I"/home/sehe/custom/boost" -MMD    -std=c++1z -c test.cpp -o
"./test.o"
"clang++"  -I"/home/sehe/custom/boost" -MMD    -std=c++1z "./test.o"  
-L"/home/sehe/custom/boost/stage/lib/" -l"boost_program_options"
-l"stdc++fs" -o "mymakemaker"
------------------------------------------------------

The resulting generated makefile looks like
https://paste.ubuntu.com/p/rMhGFxnYHy/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: mkmakefile

Boost - Dev mailing list
Seth!!
THANK YOU!!!THANK YOU!!!

:)

Greg


Quoting Seth via Boost <[hidden email]>:

> On 01-04-18 17:13, Ggh via Boost wrote:
>> wondering...if I'm reinventing the wheel ( again as many do)....I
>> guess there's loads of similar stuff
>
> Similar to what? Shell scripts that write a makefile?
>
> Also, your link was broken. The fixed link leads to incomplete code (
>
> You  don't state the target implementations (just GNU make? what
> versions?), features required, features already supported, etc.
>
> I think what I've seen is trivial. I'm not at all convinced that
> cramming the options all on some command line to be parsed by a ...
> questionable script is better than writing the equivalent makefile (or
> Makefile.am, m4 template or CMakeLists.txt, ... if you intend to
> generate the makefile).
>
> The code is... what I'd call bad code. You should probably have posted
> it for review instead (https://codereview.stackexchange.com/ e.g.).
>
> It fails to use all the conventions in place to make Makefiles
> maintainable. You subvert default variable naming (CC for CXX, really?).
>
> Here's the same program converted to actual C++ - in 306 lines of code
> (instead of the incomplete 560 lines):
> https://gist.github.com/sehe/57693dedda3de679c33848074d61c8e6/e48398e97f42071e61e2d778cdbacb4f9d0b1750
>
> Now note that *LOTS* of things have been fixed with respect to quoting
> of path names, but lots of things still don't work (no way to pass
> compiler/linker flags, static libraries aren't built (because the target
> rule was wrong), static libraries cannot link (because it needs position
> indepent code, but, again, compiler flags cannot be passed), the linker
> is always using `g++` instead of `gcc` even if all source files were
> compiled with the C compiler etc.
>
> To fix things, I cleaned things up **A LOT** MORE:
> https://gist.github.com/sehe/57693dedda3de679c33848074d61c8e6/3f22091fc4f3931ecafd3b51a93f9381ee561e2e
>
> Now the code is 351 lines of code, but actually organized (you could
> split headers and implementations here), it has actually working
>    
>      - STATICLIBTARGET and LIBTARGET
>      - much simplified rules
>      - dependency detection / creation
>      - using OBJS instead of hardcoding names and even `*.o` (ugh)
>      - separating discover_sourcefiles, generate_makefile, run_make
>      - deduceLinker (instead of using g++ to link C programs...)
>      - allow for compiler flags
>      - don't repeat includes and libraries with each (intermediate) target
>
> A screenshot of interactively bootstrapping the program using itself:
> https://imgur.com/a/AlYRz, using the command line:
>
> ./bootstrap/mymakemaker -hd -t mymakemaker -cxxflags -std=c++1z -tt exe
> -wd bootstrap -mk -cc 'clang++' -i ~/custom/boost -L
> ~/custom/boost/stage/lib/ -l boost_program_options -l stdc++fs
> Reading directory:    "bootstrap"
> Creating makefile:    makefile.mk
> Making...
> ------------------------------------------------------
> "clang++"  -I"/home/sehe/custom/boost" -MMD    -std=c++1z -c test.cpp -o
> "./test.o"
> "clang++"  -I"/home/sehe/custom/boost" -MMD    -std=c++1z "./test.o"  
> -L"/home/sehe/custom/boost/stage/lib/" -l"boost_program_options"
> -l"stdc++fs" -o "mymakemaker"
> ------------------------------------------------------
>
> The resulting generated makefile looks like
> https://paste.ubuntu.com/p/rMhGFxnYHy/
>
>
> _______________________________________________
> Unsubscribe & other changes:  
> http://lists.boost.org/mailman/listinfo.cgi/boost




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: mkmakefile

Boost - Dev mailing list
On 05-04-18 06:58, Ggh via Boost wrote:
> Seth!!
> THANK YOU!!!THANK YOU!!!
>
> :)
>
> Greg
Cheers. I don't mean to rain on your parade, but perhaps I forgot to
stress how... futile this still is.

For one thing, the complete same thing can be achieved with a relatively
straightforward standard makefile, just replacing `OBJS` with a pattern
substitution over a wildcard() call, and replacing all those "fixed"
rules with some pattern rules like:

    %.o:%.c
        $(CC) $(CFLAGS) -c $< -o $@
    %o:%.cpp
        $(CXX) $(CXXFLAGS) -c $< -o $@

    -include $(OBJS:%.o=%.d)

In fact as written, the rules for %.o are redundant as they match the
builtin defaults (at least for GNU Make), as you can find out by using
make -p.

As an example, here's a simple FIXED `Makefile` that basically
reproduces all the things you had in your C++ program, but without any
external code: https://gist.github.com/sehe/2720161cec8452c38a5eb5808a7dd919

It can build all the targets from one file, regardless of how many files
there are. In fact it's better in some respects (this makefile correctly
deals with e.g. having `a.cpp`, `a.cxx` and `a.c` all in the same
directory).

Example runs to bootstrap the same program again, this time using
**just** the one Makefile: https://i.imgur.com/boBdfID.png

Now, look at how CMake already works with ninja, Make and MSBuild. I
don't really think you are ready going to improve things yet. Of course,
you can generate your own makefiles for your own convenience, though I'd
probably write it in Python, Perl or something like that.

Regards,
Seth

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost