Page 2 of 9

Re: Waji's Standards

Posted: Thu Oct 09, 2014 8:57 pm
by Wajideu
b.zaar wrote:It looks like your plan builds a makefile, there's a thousand tools that do that kind of thing already. If make worked easily there wouldn't be a need for these. I don't have a tool to build C code, I write it myself.
This would be the first I've heard of it. The only ones I know of are autotools and cmake. The problem is that autotools is difficult to set up and depends on the crappy m4 language. All other project building tools that I know of like cmake and scons don't let you check for the existence of tools, headers, and functions; nor let you fine tune the configuration anywhere near as flexibly as autotools does.

I'm not looking for a replacement for Makefiles, I'm looking for a supplement to them. I want something that does the same thing autotools does without leaving a bunch of junk inside the project directory. Something that doesn't take an hour to configure and caches the configuration a lot better. configure.ac and Makefile.am both in one.

Re: Waji's Standards

Posted: Thu Oct 09, 2014 9:18 pm
by b.zaar
Wajideu wrote:I'm not looking for a replacement for Makefiles, I'm looking for a supplement to them. I want something that does the same thing autotools does without leaving a bunch of junk inside the project directory. Something that doesn't take an hour to configure and caches the configuration a lot better. configure.ac and Makefile.am all in one.
Why couldn't this be done in scripting in a Makefile?

Once inside a script rule you could use fexists to check if things exist. The scripting language would use a simple C like syntax with only a few functions included for file access, not the full fopen/fread/fwrite stuff, just some simple functions to extend the basic $(xxx macros. Nothing else about a typical Makefile would change.

To replace the autotools/configure scripts just include a config.mk file. Create the target config: so you would make config before the first build. A script in C syntax should be able to do what bash or m4 scripts can.

Re: Waji's Standards

Posted: Thu Oct 09, 2014 9:26 pm
by Wajideu
b.zaar wrote:
Wajideu wrote:I'm not looking for a replacement for Makefiles, I'm looking for a supplement to them. I want something that does the same thing autotools does without leaving a bunch of junk inside the project directory. Something that doesn't take an hour to configure and caches the configuration a lot better. configure.ac and Makefile.am all in one.
Why couldn't this be done in scripting in a Makfile?

Once inside a script rule you could use fexists to check if things exist. The scripting language would use a simple C like syntax with only a few functions included for file access, not the full fopen/fread/fwrite stuff, just some simple functions to extend the basic $(xxx macros. Nothing else about a typical Makefile would change.

To replace the autotools/configure scripts just include a config.mk file. Create the target config: so you would make config before the first build. A script in C syntax should be able to do what bash or m4 scripts can.
And now we're suddenly on the same page. :lol:

The whole idea of the Planfile is that it's pretty much just a Makefile with a few extra commands and target rules. When you call 'plan', it would do the configuration process; ensuring that all the required programs, headers, and functions are available and using the user-specified options. It would then spit out a Makefile which skips that configuration process, so it only has to be done once.

Re: Waji's Standards

Posted: Thu Oct 09, 2014 9:37 pm
by b.zaar
Wajideu wrote: And now we're suddenly on the same page. :lol:
Not quite...
Wajideu wrote:The whole idea of the Planfile is that it's pretty much just a Makefile with a few extra commands and target rules. When you call 'plan', it would do the configuration process; ensuring that all the required programs, headers, and functions are available and using the user-specified options. It would then spit out a Makefile which skips that configuration process, so it only has to be done once.
Why is it 2 seperate files again, first planfile then makefile?
Why not just let planfile be the makefile or add the enhancements to make so that Makefile is the Makefile?

If you want to start with an open source make I found this from here

It's not GNU compatible so that might be a problem.

I'd like to help but I'm currently wasting time on an emulator that no one wants...

Re: Waji's Standards

Posted: Thu Oct 09, 2014 9:47 pm
by Wajideu
b.zaar wrote:Why is it 2 seperate files again, first planfile then makefile?
Why not just let planfile be the makefile or add the enhancements to make so that Makefile is the Makefile?
Firstly is for speed. Having to configure the project every time you make it would be aggravating. The Makefile becomes sort of like a Planfile cache. Secondly is because of the plan-expansion process I mentioned earlier. I wanted it to take into consideration the fact that certain projects may need several build steps to complete; cases where there is often a 'tools' directory where the project builds a part of itself. Thirdly is for compatibility. Some projects could optionally be distributed with both a Planfile and a generic pre-configured Makefile for platforms that don't have the plan tool installed yet. I'd also kind of like to stick to the Makefile specification because I'm a by-the-book kind of guy.
b.zaar wrote:If you want to start with an open source make I found this from here

It's not GNU compatible so that might be a problem.

I'd like to help but I'm currently wasting time on an emulator that no one wants...
Thanks. We could also fiddle around with the GNU Make source as well. If other people actually wanna get involved, I'll go ahead and start a project on GitHub.

Re: Waji's Standards

Posted: Thu Oct 09, 2014 10:41 pm
by b.zaar
Wajideu wrote: Firstly is for speed. Having to configure the project every time you make it would be aggravating. The Makefile becomes sort of like a Planfile cache.
It would only configure when you ran

Code: Select all

make++ config
(using the new working title) otherwise it goes through the usual build process.
Wajideu wrote:Secondly is because of the plan-expansion process I mentioned earlier. I wanted it to take consideration the fact that certain projects may need several build steps to complete; cases where there is often a 'tools' directory where the project builds a part of itself.
Could this be done inside an include.mk file without it needing to be separate?

Is this run manually like

Code: Select all

make tools
or it will automatically detect it needs the build?

Couldn't this be a dependant for the target that relies on it and only build then?

Sub modules and tools directories would just be the first dependencies. I was already using this in make to build a disk image writer tool along with making the kernel and then using the tool to build the disk image all in 1 build process.

What is your example for this and do you need to run make more than once to completely build everything?

The 2nd code example I posted should be able to do this without any trouble.
Wajideu wrote:Thirdly is for compatibility. Some projects could optionally be distributed with both a Planfile and a generic pre-configured Makefile for platforms that don't have the plan tool installed yet.
What do you do for an unexpected platform that doesn't have a pre configured makefile or plan installed?

A configuration for different platforms wouldn't be hard and with a C script in the build process it would even detect and include the platform.mk file without using

Code: Select all

make -f make.win32.mk
or however you would plan to distribute the preconfigured files.

You've just created another autotools using a different language.

Re: Waji's Standards

Posted: Thu Oct 09, 2014 11:15 pm
by Muazzam
b.zaar wrote:“Be the change that you wish to see in the world.”
― Mahatma Gandhi
So, are you Indian?

Re: Waji's Standards

Posted: Thu Oct 09, 2014 11:20 pm
by b.zaar
muazzam wrote:
b.zaar wrote:“Be the change that you wish to see in the world.”
― Mahatma Gandhi
So, are you Indian?
Location: Mars MTC +6:00

Alien...

Re: Waji's Standards

Posted: Thu Oct 09, 2014 11:23 pm
by Wajideu
b.zaar wrote:It would only configure when you ran

Code: Select all

make++ config
(using the new working title) otherwise it goes through the usual build process.
You're going to want to cache that data as well somehow.
b.zaar wrote:Could this be done inside an include.mk file without it needing to be separate?
Now, you'd have 3 or more files to keep track of; the Planfile, the cache, and a .mk for each plan. In my idea, there are no separate files. You only need to write a Planfile. When you call 'plan', it'll apply the configuration and strip the Planfile down to create a Makefile.
b.zaar wrote:Is this run manually like

Code: Select all

make tools
or it will automatically detect it needs the build?
It's just adding 1 more step to the build process:

Code: Select all

plan
make all
make install
You would only need to run 'plan' if you added new sources to the project. If we wanted to automatically do this, one idea would probably be to add the Planfile itself as a target rule within the Makefile. This way, if the timestamp of the Planfile changes, it'll automatically re-plan itself.
b.zaar wrote:Couldn't this be a dependant for the target that relies on it and only build then?
That's what I was talking about in the 3rd reason I chose to use a separate file. The developer could distribute a generic Makefile alongside the Planfile. If the person has 'plan' installed, calling it would overwrite the Makefile. Otherwise, they'll fallback on the generic Makefile. This would also greatly help ease the transition into the use of Planfiles.
b.zaar wrote:Sub modules and tools directories would just be the first dependencies. I was already using this in make to build a disk image writer tool along with making the kernel and then using the tool to build the disk image all in 1 build process.

What is your example for this and do you need to run make more than once to completely build everything?
Nope, you can do it all in 1 go. I haven't worked out all the details yet, but my idea was more or less along the lines where adding a '&' prefix to a target would declare a plan and adding a '^' prefix would declare a step. Something like:

Code: Select all

&MyPlan: MyStep1 MyStep2
	@echo MyPlan built successfully
^MyStep1:
	@echo step 1
^MyStep2:
	@echo step 2
Would be expanded into something like:

Code: Select all

PLANS = MyPlan

MyPlan_STEPS = MyStep1 MyStep2

all: $(addprefix all-,$(PLANS))
build: $(addprefix build-,$(PLANS))

all-MyPlan: build-MyPlan
build-MyPlan: $(addprefix --MyPlan-,$(MyPlan_STEPS))
	@echo MyPlan built successfully
--MyPlan-MyStep1:
	@echo step 1
--MyPlan-MyStep2:
	@echo step 2
b.zaar wrote:What do you do for an unexpected platform that doesn't have a pre configured makefile or plan installed?
It's the developers choice as to whether or not they want to exclude a generic Makefile and enforce the use of Planfiles.
b.zaar wrote:You've just created another autotools using a different language.
That's pretty much the idea. I want the flexibility of autotools, without the bs that comes with it.

Re: Waji's Standards

Posted: Thu Oct 09, 2014 11:26 pm
by Muazzam
b.zaar wrote: Location: Mars MTC +6:00

Alien...
Aliens at mars does not exists.

Re: Waji's Standards

Posted: Thu Oct 09, 2014 11:36 pm
by b.zaar
muazzam wrote:
b.zaar wrote: Location: Mars MTC +6:00

Alien...
Aliens at mars does not exists.
Who do you think moved the rock?

http://www.dailymail.co.uk/sciencetech/ ... ffled.html

Re: Waji's Standards

Posted: Thu Oct 09, 2014 11:43 pm
by Brynet-Inc
muazzam wrote:Aliens at mars does not exists.
Image

Re: Waji's Standards

Posted: Thu Oct 09, 2014 11:49 pm
by b.zaar
Wajideu wrote:
b.zaar wrote:You've just created another autotools using a different language.
That's pretty much the idea. I want the flexibility of autotools, without the bs that comes with it.
So what would be your Makefile output?

Write an example output Makefile by hand that shows how to define then undefine a private variable.

Will I need to undefine every variable that was previously set if I don't want the value that is used?

Can you also show me how you would include a sub project like pdlibc as a dependency? Both as a planfile and a makefile.

Re: Waji's Standards

Posted: Thu Oct 09, 2014 11:49 pm
by Bender
muazzam wrote:
b.zaar wrote:“Be the change that you wish to see in the world.”
― Mahatma Gandhi
So, are you Indian?
AFAIK I don't think I need to be German/American to quote Albert Einstein. I think the same goes for every well-known personality.

Re: Waji's Standards

Posted: Fri Oct 10, 2014 12:16 am
by Wajideu
b.zaar wrote:Write an example output Makefile by hand that shows how to define then undefine a private variable.
I can't remember exactly how I did it before, but I did accomplish this once in the past. It was sort of hackish. I think I used a prefix for the variable name like "MyNS_VAR"; and in the target rule I expanded it with something like `$$($(addprefix MyNS_,VAR))`. IIrc, I also had to enable some feature or something that doubly expanded commands.

Another possible alternative would be to do something like:

Code: Select all

PLANS = MyPlan
.PHONY: $(addprefix all-,$(PLANS)) $(addprefix build-,$(PLANS))

all: $(addprefix all-,$(PLANS))

all-MyPlan:
	$(MAKE) -f $(lastword $(MAKEFILE_LIST)) build-MyPlan RULE=MyPlan


ifeq ($(RULE),MyPlan)
STEPS = MyStep1

SRCS = main.c

build-MyPlan: $(addprefix --MyPlan-,$(STEPS))
	@echo plan complete
--MyPlan-MyStep1:
	@echo step 1 complete
endif
b.zaar wrote:Can you also show me how you would include a sub project like pdlibc as a dependency? Both as a planfile and a makefile.
Perhaps something like this would work for the generated Makefile

Code: Select all

PROJECTS   = MySubProject
.PHONY: $(addprefix all-,$(PROJECTS))

MySubProject_DIR = My Sub Project

all: $(addprefix all-,$(PROJECTS))

all-MySubProject:
	$(MAKE) -C "$(MySubProject_DIR)" all