llvm dev - Jan 2010 - [LLVMdev] make fails to detect changes in case srcdir != objdir

On Tue, Jan 05, 2010 at 01:05:56PM -0600, David Greene
wrote:
> On Tuesday 05 January 2010 12:18, Gregory Petrosyan wrote:
> 
> > > It sounds like the dependencies for your pass are not correct. 
Where
> > > did you put it in the LLVM tree and how did you change the
Makefiles?
> >
> > One new .cpp file in lib/Transforms/IPO + RegisterPass<> +
mention pass in
> > LinkAllPasses.h; no changes in makefiles.
> 
> Hmm, that should certainly work.  What file are you touching that make
> doesn't seem to pick up?
Sorry, can't tell you that now: I've switched to srcdir == objdir
configuration.
> > > A non-build after reconfigure is not really a problem.  If
nothing in
> > > the configuration has changed configure is smart enough not to
update
> > > anything so make doesn't see any changes.
> >
> > Yes, but in my case support for new targets should be built in.
> 
> What do you mean?
I've done these:

	1) configure --enable-targets=x86
	2) make
	3) configure --enable-targets=all
	4) make

and after it I still did not had e.g. C backend.
> > It is entirely possible that I've screwed something up, although
I've tried
> > to follow LLVM docs as closely as possible. LLVM build system is
really not
> > the nicest part of LLVM :-)
> 
> That's true, but that's autoconf's fault, not LLVM's.  :)
And what was the reason for picking autoconf?

	Gregory

On Tuesday 05 January 2010 13:33, Gregory Petrosyan wrote:
> > > > A non-build after reconfigure is not really a problem.  If
nothing in
> > > > the configuration has changed configure is smart enough not
to update
> > > > anything so make doesn't see any changes.
> > >
> > > Yes, but in my case support for new targets should be built in.
> >
> > What do you mean?
>
> I've done these:
>
> 	1) configure --enable-targets=x86
> 	2) make
> 	3) configure --enable-targets=all
> 	4) make
>
> and after it I still did not had e.g. C backend.
Ah.  I actually don't know what configure does in that case.  I suppose
it depends on what .in files actually use the target list.  This could be
a real problem, I just don't know enough about the build system to be sure.
> > > It is entirely possible that I've screwed something up,
although I've
> > > tried to follow LLVM docs as closely as possible. LLVM build
system is
> > > really not the nicest part of LLVM :-)
> >
> > That's true, but that's autoconf's fault, not LLVM's. 
:)
>
> And what was the reason for picking autoconf?
Don't ask me, it's not what I would have done.  :)

But to be fair, at the time autoconf was really the only game in town.
Even now, only CMake really competes in this space.

Then again, neither one satisfies Joel Test #2:

http://www.joelonsoftware.com/articles/fog0000000043.html

I've wondered for a long time why software systems don't build a build
system
around a tool that's actually designed for it.  Like make.  In fact I
wondered
so much that I went and did it.  Parallel configure/build/test is a really
nifty thing.  It's fun seeing regression tests running before the software
build is complete.  :)

Make is not everyone's cup of tea but for those of us crazy enough to write
in
something akin to declarative LISP, it's a nice diversion from boring old 
C++ metaprogramming.  :)

                                  -Dave

\>> I've done these:
>>
>>       1) configure --enable-targets=x86
>>       2) make
>>       3) configure --enable-targets=all
>>       4) make
>>
>> and after it I still did not had e.g. C backend.
>
> Ah.  I actually don't know what configure does in that case.  I suppose
> it depends on what .in files actually use the target list.  This could be
> a real problem, I just don't know enough about the build system to be
sure.
I think in this situation the second configure uses the cached stuff
from the first run...

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

On 2010-01-05 22:21, David Greene wrote:
> On Tuesday 05 January 2010 13:33, Gregory Petrosyan wrote:
>
>   
>>>>> A non-build after reconfigure is not really a problem.  If
nothing in
>>>>> the configuration has changed configure is smart enough not
to update
>>>>> anything so make doesn't see any changes.
>>>>>           
>>>> Yes, but in my case support for new targets should be built in.
>>>>         
>>> What do you mean?
>>>       
>> I've done these:
>>
>> 	1) configure --enable-targets=x86
>> 	2) make
>> 	3) configure --enable-targets=all
>> 	4) make
>>
>> and after it I still did not had e.g. C backend.
>>     
>
> Ah.  I actually don't know what configure does in that case.  I suppose
> it depends on what .in files actually use the target list.  This could be
> a real problem, I just don't know enough about the build system to be
sure.
>
>   
>>>> It is entirely possible that I've screwed something up,
although I've
>>>> tried to follow LLVM docs as closely as possible. LLVM build
system is
>>>> really not the nicest part of LLVM :-)
>>>>         
>>> That's true, but that's autoconf's fault, not
LLVM's.  :)
>>>       
>> And what was the reason for picking autoconf?
>>     
>
> Don't ask me, it's not what I would have done.  :)
>
> But to be fair, at the time autoconf was really the only game in town.
> Even now, only CMake really competes in this space.
>
> Then again, neither one satisfies Joel Test #2:
>
> http://www.joelonsoftware.com/articles/fog0000000043.html
>
> I've wondered for a long time why software systems don't build a
build system
> around a tool that's actually designed for it.  Like make.  In fact I
wondered
> so much that I went and did it.  Parallel configure/build/test is a really
> nifty thing.  It's fun seeing regression tests running before the
software
> build is complete.  :)
>   
Slightly offtopic, I noticed this project which does something very
similar to what you describe:
http://code.google.com/p/quagmire/

I don't know what its current state is, but is something worth keeping
an eye on IMHO.

Best regards,
--Edwin