build_idl.sh portability

David Disseldorp ddiss at suse.de
Sun Jun 3 08:49:30 MDT 2012


Hi Andrew,

On Sat, 02 Jun 2012 16:59:51 +1000
Andrew Bartlett <abartlet at samba.org> wrote:

> I wonder if we could revert the changes you made for bug
> https://bugzilla.samba.org/show_bug.cgi?id=8865
> 
> It uses some complex shell scripting, and causes issues on Tru64, which
> in turn makes it harder to compare the true portability or otherwise of
> the waf and autoconf builds. 
> 
> https://build.samba.org/build.cgi/build/a029088ee29607e8afe0b15154cfc80be698c21a

Looks like it's the "$(...)" expression syntax that's causing problems,
as pointed out by Volkers proposed fix. One other option may be to
revert 15c60456 and go back to the initial Perl based logic.

> Perhaps we could replace it with having ./autogen.sh simply
> unconditionally rebuilding the IDL?
> 
> Then, given that pidl (and even IDL) changes are rare, it seems
> reasonable to me that developers should just run ./autogen.sh if it
> changes.  

An unconditional rebuild would certainly make things simpler, but
given the amount of IDL now days there's a pretty significant time
saving in having a change dependent build.

Forcing manual intervention to recompile when the pidl compiler is
changed is unacceptable IMO, as the consequences can be serious, i.e.
pulling in the fixes for CVE-2012-1182 but having a build that still
includes the vulnerabilities.

> If we want file-time based dependencies, then we should use make (that
> is what is is for, isn't it?), rather than having a mini-build system in
> a shell script.  Conceptually I would prefer that we did our perl-based
> building in either Makefile.in or autogen.sh, but not both. 

Yes, I agree. I'd prefer to see the IDL compiled in the make file only.
Unfortunately it's apparently required for configure tests, I've not
checked which ones.

Cheers, David


More information about the samba-technical mailing list