Closed Bug 468915 Opened 16 years ago Closed 15 years ago

comm-central build fails if built in srcdir

Categories

(MailNews Core :: Build Config, defect)

All
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wuno, Unassigned)

Details

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre) Gecko/20081209 Minefield/3.2a1pre
Build Identifier: 

In the gentoo build system, mozilla apps are built in the srcdir. This works with firefox and xulrunner and used to work with thunderbird before the move of the tree to comm-central. Now, the gecko components in the mozilla subdirectory get built successfully. However, when the Makefiles of comm-central should be generated, the make-makefile.pl script residing in mozilla/build/autoconf directory doesn't get found:

/usr/bin/perl ./mozilla/build/autoconf/make-makefile -t ../../.. -d ../../..  modules/Makefile
gmake[4]: Entering directory `/var/tmp/portage/mail-client/shredder-9999/work/src/mailnews/db/msgdb'
Can't open perl script "./mozilla/build/autoconf/make-makefile": No such file or directory
gmake[5]: Entering directory `/var/tmp/portage/mail-client/shredder-9999/work/src/mailnews/db/msgdb/public'
gmake[4]: *** [modules/Makefile] Error 2
gmake[4]: Leaving directory `/var/tmp/portage/mail-client/shredder-9999/work/src/mailnews/db/gloda'
gmake[3]: *** [db/gloda_export] Error 2
gmake[3]: *** Waiting for unfinished jobs....

So far I analyzed that comm-central/config/config.mk defines
AUTOCONF_TOOLS = $(MOZILLA_SRCDIR)/build/autoconf
and in comm-central/config/rules.mk the perl script gets called by
@$(PERL) $(AUTOCONF_TOOLS)/make-makefile -t $(topsrcdir) -d $(DEPTH) $(CYGWIN_TOPSRCDIR)

$MOZILLA_SRCDIR gets defined in configure.in as $topsrcdir/mozilla early and at this is resolved in srcdir builds then to ./mozilla
When I exchange in config/config.mk $(MOZILLA_SRCDIR) against $topsrcdir/mozilla the make-makefile.pl script is found correctly. However then the build fails a bit later again when it does not find build-list.pl

/usr/bin/perl -I./mozilla/config ./mozilla/config/build-list.pl ../../../../mozilla/config/final-link-libs mimecthglue_s
Can't open perl script "./mozilla/config/build-list.pl": Datei oder Verzeichnis nicht gefunden
/var/tmp/portage/mail-client/shredder-9999/work/src/mozilla/config/nsinstall -R -m 644 nsIPop3IncomingServer.idl nsIPop3Service.idl nsIMailboxService.idl nsIPop3Sink.idl nsIPop3URL.idl nsIMailboxUrl.idl 
nsIMsgParseMailMsgState.idl nsINoIncomingServer.idl nsINoneService.idl nsIMsgLocalMailFolder.idl nsILocalMailIncomingServer.idl nsIPop3Protocol.idl nsIRssIncomingServer.idl nsIRssService.idl nsINewsBlogF
eedDownloader.idl nsIMovemailService.idl nsIMovemailIncomingServer.idl ../../../mozilla/dist/idl
gmake[6]: *** [export] Error 2
from comm-central/config/rules.mk
@$(PERL) -I$(MOZILLA_DIR)/config $(MOZILLA_DIR)/config/build-list.pl $(FINAL_LINK_COMPS) $(LIBRARY_NAME)
in this case $(MOZILLA_DIR) that was defined at the top of rules.mk to be the same as $(MOZILLA_SRCDIR) is also set to ./mozilla

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Product: Core → MailNews Core
QA Contact: build-config → build-config
Target Milestone: --- → Thunderbird 3.0b2
Version: unspecified → Trunk
Target Milestone: Thunderbird 3.0b2 → ---
Just for analysis, what happens if you define the env var |OBJDIR=$topsrcdir| before starting the build?
(In reply to comment #1)
> Just for analysis, what happens if you define the env var |OBJDIR=$topsrcdir|
> before starting the build?
Tried this env var and several others like topsrcdir=`pwd`, nothing helped.
The problem is that in a srcdir build $topsrcdir=. (a dot) and then MOZILLA_SRCDIR gets "hardcoded" as "./mozilla", you can see this also in config.status. In the mozilla-tree MOZILLA_SRCDIR is saved as $topsrcdir, which gets redefined according to the subdir it was called from.
The most elegant way would be to save the variable $topsrcdir in $MOZILLA_SRCDIR as a nested variable, but I found no propper way to do it.
In an objdir build $topsrcdir gets always resolved to its full path. Thus, with respect to an objdir build the patch in fact doesn't change anything, but for an srcdir build the mozilla tree is now found.
Attachment #352837 - Flags: review?(kairo)
(In reply to comment #2)
> Created an attachment (id=352837) [details]
> set MOZILLA_SRCDIR to the full path
> 
...
> Thus, with
> respect to an objdir build the patch in fact doesn't change anything, but for
> an srcdir build the mozilla tree is now found.

I can't test it at the moment but, after doing an objdir build started from the comm-central directory with make -f client.mk build, won't this now leave you in the mozilla/ directory rather than the comm-central directory? or does something else make us cd back to the comm-central directory?
I'm not convinced on using the absolute path there yet, I still wonder if we could go for a more parameterized approach, esp. for Makefiles this should be doable some way.
(In reply to comment #3)
> (In reply to comment #2)
> > Created an attachment (id=352837) [details] [details]
> > set MOZILLA_SRCDIR to the full path
> > 
> ...
> > Thus, with
> > respect to an objdir build the patch in fact doesn't change anything, but for
> > an srcdir build the mozilla tree is now found.
> 
> I can't test it at the moment but, after doing an objdir build started from the
> comm-central directory with make -f client.mk build, won't this now leave you
> in the mozilla/ directory rather than the comm-central directory? or does
> something else make us cd back to the comm-central directory?
If I understood it correctly, we don't use $MOZILLA_SRCDIR for changing directories

Well, I modified the current configure.in in comm-central by adding an echo to get the output for $MOZILLA_SRCDIR

MOZILLA_SRCDIR=$topsrcdir/mozilla
echo MOZILLA_SRCDIR=$MOZILLA_SRCDIR
AC_CONFIG_AUX_DIR(${MOZILLA_SRCDIR}/build/autoconf)

These are the outputs with configure.in as is at the moment 
objdir set to $topsrcdir/obj in .mozconfig
objdir build:
    MOZ_OBJDIR=/var/tmp/portage/mail-client/shredder-9999/work/src/obj
make[1]: Entering directory `/var/tmp/portage/mail-client/shredder-9999/work/src
'
cd /var/tmp/portage/mail-client/shredder-9999/work/src/obj
/var/tmp/portage/mail-client/shredder-9999/work/src/configure
[snip]
  --enable-extensions=default
creating cache ./config.cache
MOZILLA_SRCDIR=/var/tmp/portage/mail-client/shredder-9999/work/src/mozilla
[snip]
config.status
s%@COMM_BUILD@%1%g
s%@MOZILLA_SRCDIR@%/var/tmp/portage/mail-client/shredder-9999/work/src/mozilla%g
s%@MOZ_DEB_TIMESTAMP@%Sat, 13  Dec 2008 21:37:07 +0100%g

running ./configure in the $topsrcdir
Adding configure options from ./.mozconfig:
[snip]
  --enable-extensions=default
loading cache ./config.cache
MOZILLA_SRCDIR=./mozilla
[snip]
config.status:
[snip]
s%@COMM_BUILD@%1%g
s%@MOZILLA_SRCDIR@%./mozilla%g
s%@MOZ_DEB_TIMESTAMP@%Sat, 13  Dec 2008 21:56:23 +0100%g
[snip]

With the attachment (id=352837) applied
objdir build
    MOZ_OBJDIR=/var/tmp/portage/mail-client/shredder-9999/work/src/obj
make[1]: Entering directory `/var/tmp/portage/mail-client/shredder-9999/work/src'
cd /var/tmp/portage/mail-client/shredder-9999/work/src/obj
/var/tmp/portage/mail-client/shredder-9999/work/src/configure
[snip]
  --enable-extensions=default
loading cache ./config.cache
MOZILLA_SRCDIR=/var/tmp/portage/mail-client/shredder-9999/work/src/mozilla
[snip]
config.status
[snip]
s%@COMM_BUILD@%1%g
s%@MOZILLA_SRCDIR@%/var/tmp/portage/mail-client/shredder-9999/work/src/mozilla%g
s%@MOZ_DEB_TIMESTAMP@%Sat, 13  Dec 2008 22:18:14 +0100%g
[snip]

srcdir build: ./configure in $topsrcdir
Adding configure options from ./.mozconfig:
[snip]
  --enable-extensions=default
creating cache ./config.cache
MOZILLA_SRCDIR=/var/tmp/portage/mail-client/shredder-9999/work/src/mozilla
[snip]
config.status:
s%@COMM_BUILD@%1%g
s%@MOZILLA_SRCDIR@%/var/tmp/portage/mail-client/shredder-9999/work/src/mozilla%g
s%@MOZ_DEB_TIMESTAMP@%Sat, 13  Dec 2008 22:20:36 +0100%g

(In reply to comment #4)
> I'm not convinced on using the absolute path there yet, I still wonder if we
> could go for a more parameterized approach, esp. for Makefiles this should be
> doable some way.
In fact, the absolute path is used in an objdir build. The Makefiles are not the problem in the srcdir build, the problems are perl scripts and other included files that should be invoked from the mozilla/ tree (which is set to ./mozilla at the moment)
> AUTOCONF_TOOLS = $(MOZILLA_SRCDIR)/build/autoconf
> and in comm-central/config/rules.mk the perl script gets called by
> @$(PERL) $(AUTOCONF_TOOLS)/make-makefile -t $(topsrcdir) -d $(DEPTH) $(CYGWIN_TOPSRCDIR)
> /usr/bin/perl ./mozilla/build/autoconf/make-makefile -t ../../.. -d ../../.. 
modules/Makefile
Alternatively, if we don't use AC_SUBST(MOZILLA_SRCDIR) in configure.in, we could set in configure/autoconf.mk.in MOZILLA_SRCDIR to the variable $(topsrcdir)/mozilla. At least at the moment autoconf.mk.in is the _only_ file where @MOZILLA_SRCDIR@ get substituted, and it gets substituted by the value of MOZILLA_SRCDIR that is ./mozilla in srcdir builds (full path in objdir builds). The only way I found to get @MOZILLA_SRCDIR@ substituted by $topsrcdir/mozilla is to set MOZILLA_SRCDIR='$topsrcdir/mozilla' (with single quotes) but then configure fails because it needs the value of the MOZILLA_SRCDIR variable. Going not for r yet but it would be nice if Mark or KaiRo could comment.
Attachment #352837 - Attachment is obsolete: true
Attachment #352837 - Flags: review?(kairo)
Attachment #353268 - Flags: review?(kairo)
Attachment #353268 - Flags: review?(kairo) → review+
Comment on attachment 353268 [details] [diff] [review]
works w/o full path

As much as I don't want to spread hardcoding the subdir as "mozilla" too far, autoconf.mk.in is already infected with this, so I guess this is OK.
Keywords: checkin-needed
Checked in: http://hg.mozilla.org/comm-central/rev/3c9ee88189c1
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite-
Keywords: checkin-needed
Resolution: --- → FIXED
This affects building Thunderbird 3.0b1 and earlier from source.  Can someone please add this to:  http://www.mozillamessaging.com/en-US/thunderbird/3.0b1/releasenotes/#troubleshooting
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: