Hi,
I’m looking at tidying up some existing makefile logic and noticed there isn’t
a lot of consistency in the format of conditionals - especially from myself
over the years. We use make for build automation, not directly for compilation,
and don’t use any pre-processor conditionals in this con
> On 18 Oct 2015, at 01:12, Rakesh Sharma wrote:
>
> Tony Theodore me.com> writes:
>
>>
>> Is this a reasonable idea and is there any chance $(else) will have some
>> defined value in the future?
>>
>
> This is not at all a good idea, since i
> On 20 Oct 2015, at 20:47, Mark Galeck wrote:
>
> Dan Kegel wrote:
> You may need this commit, which was after 4.1, if I read git history
> correctly:
>
> commit 292da6f6867b75a5af7ddbb639a1feae022f438f
> Author: Paul Smith
> Date: Mon Oct 20 01:54:56 2014 -0400
>
>* main.c (main): [SV
> On 20 Oct 2015, at 20:47, Mark Galeck wrote:
>
> Well, if I persist and try
>
>> autoreconf -i
> again, it gives the warning as above but no more error. (??) I can then do
> ./configure , but then
>
>> make
>
> fails to build.
There’s a ‘make update’ there that you may have missed. It
> On 30 Jun 2016, at 04:50, Paul Smith wrote:
>
> However, you should generally not have targets depend on directories,
> because make treats them just like any other file when it checks
> modification times; however directories do not act like normal files
> when it comes to modification times.
> On 15 Jul 2016, at 01:46, Adrian Muresan wrote:
>
[…]
>
> What I need is an OS utility that will detect every read/write action my
> build performs AND the ability to attribute
>
> those filesystem-level operations to the makefile target that performs them.
Not exactly an OS utility, but G
> On Wed, 2016-08-17 at 06:26 +, zhi zunbao wrote:
>> i wanna build a linux according to the lfs 7.7.
>>
>>
>> afte i execute the code below:
>>
>> chroot "$LFS" /tools/bin/env -i \
>> HOME=/root \
>> TERM="$TERM"\
>> PS1='\u:\w\$ '
Hi,
Looking at an example of a canned recipe in:
https://www.gnu.org/software/make/manual/make.html#Eval-Function
define PROGRAM_template =
$(1): $$($(1)_OBJS) $$($(1)_LIBS:%=-l%)
ALL_OBJS += $$($(1)_OBJS)
endef
$(foreach prog,$(PROGRAMS),$(eval $(call PROGRAM_template,$
> On 13 Mar 2017, at 02:10, Paul Smith wrote:
>
> Yes, absolutely. The point of the foreach function is that the loop
> variable is visible in the scope of the loop body... otherwise foreach
> is almost useless.
Thanks, I just realised I don’t need to use `call` at all in the case
where the po
> On 13 Mar 2017, at 02:02, LeJacq, Jean Pierre
> wrote:
>
> Tony Theodore wrote:
>
>> It seems the variable `prog` is in scope from the calling loop and
>> can be referenced in the template:
>>
>>define PROGRAM_template =
>> $
> On 3 Apr 2024, at 20:52, anand akhare wrote:
>
> My idea is that intermediate values of variable should be used until changed
> for target and recipe. Same behavior is seen with non-recursive variables.
> (like VAR:=abc)
You probably want target-specific variables to achieve that behaviour
> On 4 Apr 2024, at 18:10, anand akhare wrote:
>
> Hello Tony
> I am looking for confirmation if this is expected behavior. Target
> specific variables will not have visibility outside of its recipe. I am using
> VAR variable across makefile.
I’m out of my depth. Five years ago I could
> On 28 Sep 2019, at 16:21, nikhil jain wrote:
>
> Do you mean to not use -j ?
>
> That means a single rule execution at a time. It takes 2 hours to build.
> With -j4 it takes 1 hour.
>
> I have -j kind of unlimited. So it usually takes around just 5 minutes to
> build. Less than that sometim
13 matches
Mail list logo
