1292653 - old-configure invokes subconfigure script in parent of srcdir

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[Myk Melez [:myk] [@mykmelez]]

For Positron, I'd like to specify a subconfigured directory (positron/app/spidernode) in its app-specific configure script (positron/configure.in):

  AC_OUTPUT_SUBDIRS(positron/app/spidernode)

When I do so, however, old-configure invokes [path to srcdir]/../positron/app/spidernode/configure instead of [path to srcdir]/positron/app/spidernode/configure.

It looks like this is because of a change in bug 1035599 that sets srcdir to srcdir/.. when invoking a subconfigure script.  Reverting that change fixes the problem, although presumably it breaks comm-central's usage.  I'm not very familiar with this code, so I'm unsure how to accommodate both usages.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

Attachment: Bug 1292653 - invoke subconfigure script from original srcdir;

Review commit: https://reviewboard.mozilla.org/r/69718/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/69718/

Comment 2

[Myk Melez [:myk] [@mykmelez]]

glandium: the patch I just attached reverts the previous change, which fixes Positron's intended usage.  As I mentioned in my previous comment, this presumably breaks comm-central's usage.  Can you suggest a change that would be compatible with both usages?

Comment 3

[Mike Hommey [:glandium]]

Comment on attachment 8778419 [details]
Bug 1292653 - invoke subconfigure script from original srcdir;

https://reviewboard.mozilla.org/r/69718/#review68578

The "use stuff from $MOZ_BUILD_APP/configure.in" is legacy and kept for comm-central. It is not meant to be used by anything new. This is why there is a ".." hardcoded there to make this thing work for comm-central, and that is why it doesn't work for you because it's not meant to.

There is not much in your positron/configure.in so you /could/ transpose to positron/moz.configure. But that doesn't seem very desirable either. I think a better option would be to use the gyp integration in moz.build. It probably is insufficient for spidernode, but Ted is going to improve it to support NSS, so I guess you'll be covered by that. Although I don't know how the whole "depend on an external build system (spidernode) to build part of our stuff (spidermonkey)" is supposed to work out. Although now looking at spidernode/configure, it looks like this is going to be very painful...

Comment 4

[Myk Melez [:myk] [@mykmelez]]

(In reply to Mike Hommey [:glandium] from comment #3)
> Comment on attachment 8778419 [details]
> Bug 1292653 - invoke subconfigure script from original srcdir;
> 
> https://reviewboard.mozilla.org/r/69718/#review68578
> 
> The "use stuff from $MOZ_BUILD_APP/configure.in" is legacy and kept for
> comm-central. It is not meant to be used by anything new. This is why there
> is a ".." hardcoded there to make this thing work for comm-central, and that
> is why it doesn't work for you because it's not meant to.

Ok, fair enough, I'll find another way to do this.


> There is not much in your positron/configure.in so you /could/ transpose to
> positron/moz.configure. But that doesn't seem very desirable either. I think
> a better option would be to use the gyp integration in moz.build. It
> probably is insufficient for spidernode, but Ted is going to improve it to
> support NSS, so I guess you'll be covered by that.

I've been testing Ted's patch, and it's helpful but insufficient.  The ability to disable gyp_chromium-specific configuration is useful, but for SpiderNode I also need to:

1. use a newer version of GYP that supports the conditional syntax in SpiderNode's GYP configuration;
2. specify additional GYP include (.gypi) files;
3. generate a GYP include file by running the configure script in the SpiderNode root directory.

(There may be other issues as well.  These are just the ones I've encountered so far.)

I filed bug 1296798 on the first issue and have attached patches.  I have a work-in-progress pull request for the second issue over in https://github.com/mozilla/positron/pull/112.  But I'm not sure how to address the third issue, except perhaps by transposing to positron/moz.configure and invoking the SpiderNode configure script there.  Do you have any alternative suggestions?

Comment 5

[(not currently active) Ted Mielczarek]

For NSS, there are some things in the configure.gypi that are autoconf-like and I simply pass the values I want in in `gyp_vars`, like:
https://hg.mozilla.org/try/file/5c059a81dcdf/security/moz.build#l21