notion-devel

[Notion-devel] Another obscure build peculiarity (in libextl this time)

[Ole J. B. <ole...@ya...>]

If you do a 'make -j2' first, and for some weird reason do a 'make -j2' again, realize you have to change the lua settings in system.mk, do a 'make clean', and then 'make -j2' again, the changes has not propagated to the shebang in 'libextl-mkexports'.

or maybe better:

# make sure lua config is wrong
make realclean
make -j2
make -j2
# check that libextl-mkexports has appeared
# fix lua config
make clean
make
make install
# -> libextl-mkexports fails to run. (wrong shebang)

This only happens when running 'make -j2'. For some reason you have to run it twice to get the effect, although that could be coincidence related to scheduling?

The reason is that 'make clean' does not remove 'libextl-mkexports', and the source ('libextl-mkexports.in') contains a "macro", expanded by the makefile:

   libextl-mkexports: libextl-mkexports.in
   	sed "1s:LUA50:$(LUA):" $< > $@

'libextl-mkexports' is thus not remade, and the shebang remains unchanged. You wont realize the error until you try to run 'libextl-mkexports' (ie. when building notion/ion3), since the build succeeds.

'make realclean' removes the file, but it's not exactly obvious...

Again.. a fairly obscure(*) problem ;)

(*) Apart from the 'make -j2', and for some reason running make twice, I think you'd only see this when you change your lua install location. eg. from the deb package to upstream.

Easiest fix (if deemed worthwhile) is either to add the *.mk files as dependencies to the 'libextl-mkexports' target, or add 'libextrl-mkexports' to the clean list. (line 136 in 'build/rules.mk'). (Well, according to my limited make knowledge at least)

- Ole Jørgen Brnner

Re: [Notion-devel] Another obscure build peculiarity (in libextl this time)

[Arnout E. <no...@bz...>]

Hi,

I can confirm the issue.

Adding *.mk to the dependencies seems a bit odd, as basically everything is 
dependent on those and it's uncommon to list them as dependencies.

Adding libextrl-mkexports to the 'clean' list seems like a bad idea: afaics the
convention is that 'make clean' will not clean the 'deliverables': in principle
you should be able to 'make install' even after having done 'make clean'.

A third option might be to specify that libextrl-mkexports always needs to be
rebuilt, regardless of whether its dependencies have changed. This can be done
by:

.PHONY : libextrl-mkexports

This might be a GNU thing, but we're GNU Make-specific anyway. 

Thoughts?


Kind regards,

Arnout

On Tue, Feb 15, 2011 at 10:39:06PM +0100, Ole Jørgen Brønner wrote:
> If you do a 'make -j2' first, and for some weird reason do a 'make -j2' again, realize you have to change the lua settings in system.mk, do a 'make clean', and then 'make -j2' again, the changes has not propagated to the shebang in 'libextl-mkexports'.
> 
> or maybe better:
> 
> # make sure lua config is wrong
> make realclean
> make -j2
> make -j2
> # check that libextl-mkexports has appeared
> # fix lua config
> make clean
> make
> make install
> # -> libextl-mkexports fails to run. (wrong shebang)
> 
> This only happens when running 'make -j2'. For some reason you have to run it twice to get the effect, although that could be coincidence related to scheduling?
> 
> The reason is that 'make clean' does not remove 'libextl-mkexports', and the source ('libextl-mkexports.in') contains a "macro", expanded by the makefile:
> 
>    libextl-mkexports: libextl-mkexports.in
>    	sed "1s:LUA50:$(LUA):" $< > $@
> 
> 'libextl-mkexports' is thus not remade, and the shebang remains unchanged. You wont realize the error until you try to run 'libextl-mkexports' (ie. when building notion/ion3), since the build succeeds.
> 
> 'make realclean' removes the file, but it's not exactly obvious...
> 
> Again.. a fairly obscure(*) problem ;)
> 
> (*) Apart from the 'make -j2', and for some reason running make twice, I think you'd only see this when you change your lua install location. eg. from the deb package to upstream.
> 
> Easiest fix (if deemed worthwhile) is either to add the *.mk files as dependencies to the 'libextl-mkexports' target, or add 'libextrl-mkexports' to the clean list. (line 136 in 'build/rules.mk'). (Well, according to my limited make knowledge at least)
> 
> - Ole Jørgen Brnner
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel

Re: [Notion-devel] Another obscure build peculiarity (in libextl this time)

[<eb...@dr...>]

If you have config.h from some automake/autoconf, then all your
sources also depends on it. Thus I think that system.mk and
build/libs.mk should be general prerequisities (i.e., everything depends
on that). Only on these two, they are the locations where, e.g.,
CFLAGS are set.


On Wed, 16 Feb 2011 00:07:29 +0100
Arnout Engelen <no...@bz...> wrote:
> Hi,
> 
> I can confirm the issue.
> 
> Adding *.mk to the dependencies seems a bit odd, as basically
> everything is dependent on those and it's uncommon to list them as
> dependencies.
> 
> Adding libextrl-mkexports to the 'clean' list seems like a bad idea:
> afaics the convention is that 'make clean' will not clean the
> 'deliverables': in principle you should be able to 'make install'
> even after having done 'make clean'.
> 
> A third option might be to specify that libextrl-mkexports always
> needs to be rebuilt, regardless of whether its dependencies have
> changed. This can be done by:
> 
> .PHONY : libextrl-mkexports
> 
> This might be a GNU thing, but we're GNU Make-specific anyway. 
> 
> Thoughts?
> 
> 
> Kind regards,
> 
> Arnout
> 
> On Tue, Feb 15, 2011 at 10:39:06PM +0100, Ole Jørgen Brønner wrote:
> > If you do a 'make -j2' first, and for some weird reason do a 'make
> > -j2' again, realize you have to change the lua settings in
> > system.mk, do a 'make clean', and then 'make -j2' again, the
> > changes has not propagated to the shebang in 'libextl-mkexports'.
> > 
> > or maybe better:
> > 
> > # make sure lua config is wrong
> > make realclean
> > make -j2
> > make -j2
> > # check that libextl-mkexports has appeared
> > # fix lua config
> > make clean
> > make
> > make install
> > # -> libextl-mkexports fails to run. (wrong shebang)
> > 
> > This only happens when running 'make -j2'. For some reason you have
> > to run it twice to get the effect, although that could be
> > coincidence related to scheduling?
> > 
> > The reason is that 'make clean' does not remove
> > 'libextl-mkexports', and the source ('libextl-mkexports.in')
> > contains a "macro", expanded by the makefile:
> > 
> >    libextl-mkexports: libextl-mkexports.in
> >    	sed "1s:LUA50:$(LUA):" $< > $@
> > 
> > 'libextl-mkexports' is thus not remade, and the shebang remains
> > unchanged. You wont realize the error until you try to run
> > 'libextl-mkexports' (ie. when building notion/ion3), since the
> > build succeeds.
> > 
> > 'make realclean' removes the file, but it's not exactly obvious...
> > 
> > Again.. a fairly obscure(*) problem ;)
> > 
> > (*) Apart from the 'make -j2', and for some reason running make
> > twice, I think you'd only see this when you change your lua install
> > location. eg. from the deb package to upstream.
> > 
> > Easiest fix (if deemed worthwhile) is either to add the *.mk files
> > as dependencies to the 'libextl-mkexports' target, or add
> > 'libextrl-mkexports' to the clean list. (line 136 in
> > 'build/rules.mk'). (Well, according to my limited make knowledge at
> > least)
> > 
> > - Ole Jørgen Brnner
> > 
> > ------------------------------------------------------------------------------
> > The ultimate all-in-one performance toolkit: Intel(R) Parallel
> > Studio XE: Pinpoint memory and threading errors before they happen.
> > Find and fix more than 250 security defects in the development
> > cycle. Locate bottlenecks in serial and parallel code that limit
> > performance. http://p.sf.net/sfu/intel-dev2devfeb
> > _______________________________________________
> > Notion-devel mailing list
> > Not...@li...
> > https://lists.sourceforge.net/lists/listinfo/notion-devel
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
> XE: Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel
> 


-- 
                                 Tomáš 'ebík' Ebenlendr
                                 PF 2011.12667278666

Re: [Notion-devel] Another obscure build peculiarity (in libextl this time)

[Ole J. B. <ole...@ya...>]

Agreed, an extra sed can't be that bad? (to the extend that anything needs to be done)

Hopefully my next inquiry will be of a less nitpicking character ;)


On Wed, 16 Feb 2011 00:07:29 +0100, Arnout Engelen <no...@bz...> wrote:

> Hi,
>
> I can confirm the issue.
>
> Adding *.mk to the dependencies seems a bit odd, as basically everything is
> dependent on those and it's uncommon to list them as dependencies.
>
> Adding libextrl-mkexports to the 'clean' list seems like a bad idea: afaics the
> convention is that 'make clean' will not clean the 'deliverables': in principle
> you should be able to 'make install' even after having done 'make clean'.
>
> A third option might be to specify that libextrl-mkexports always needs to be
> rebuilt, regardless of whether its dependencies have changed. This can be done
> by:
>
> .PHONY : libextrl-mkexports
>
> This might be a GNU thing, but we're GNU Make-specific anyway.
>
> Thoughts?
>
>
> Kind regards,
>
> Arnout
>
> On Tue, Feb 15, 2011 at 10:39:06PM +0100, Ole Jørgen Brønner wrote:
>> If you do a 'make -j2' first, and for some weird reason do a 'make -j2' again, realize you have to change the lua settings in system.mk, do a 'make clean', and then 'make -j2' again, the changes has not propagated to the shebang in 'libextl-mkexports'.
>>
>> or maybe better:
>>
>> # make sure lua config is wrong
>> make realclean
>> make -j2
>> make -j2
>> # check that libextl-mkexports has appeared
>> # fix lua config
>> make clean
>> make
>> make install
>> # -> libextl-mkexports fails to run. (wrong shebang)
>>
>> This only happens when running 'make -j2'. For some reason you have to run it twice to get the effect, although that could be coincidence related to scheduling?
>>
>> The reason is that 'make clean' does not remove 'libextl-mkexports', and the source ('libextl-mkexports.in') contains a "macro", expanded by the makefile:
>>
>>    libextl-mkexports: libextl-mkexports.in
>>    	sed "1s:LUA50:$(LUA):" $< > $@
>>
>> 'libextl-mkexports' is thus not remade, and the shebang remains unchanged. You wont realize the error until you try to run 'libextl-mkexports' (ie. when building notion/ion3), since the build succeeds.
>>
>> 'make realclean' removes the file, but it's not exactly obvious...
>>
>> Again.. a fairly obscure(*) problem ;)
>>
>> (*) Apart from the 'make -j2', and for some reason running make twice, I think you'd only see this when you change your lua install location. eg. from the deb package to upstream.
>>
>> Easiest fix (if deemed worthwhile) is either to add the *.mk files as dependencies to the 'libextl-mkexports' target, or add 'libextrl-mkexports' to the clean list. (line 136 in 'build/rules.mk'). (Well, according to my limited make knowledge at least)
>>
>> - Ole Jørgen Brnner