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