texlive-bin is not UsingTheRightCompiler

[ryandesign (Ryan Carsten Schmidt)]

While compiling texlive-bin I see this one line which is not UsingTheRightCompiler:

:info:build g++ -DHAVE_CONFIG_H -I. -I./w2c  -I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_tex_texlive-bin/texlive-bin/work/texlive-source-20130619-stripped/texk -I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_tex_texlive-bin/texlive-bin/work/texlive-source-20130619-stripped/texk -I./xetexdir -DXETEX_BUILD_DATE="\"`date +%Y%m%d%H`\"" -I/opt/local/include  -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_tex_texlive-bin/texlive-bin/work/texlive-source-20130619-stripped/libs/teckit/include -I/opt/local/include/harfbuzz  -I/opt/local/include  -DXETEX_MAC   -isystem/opt/local/include  -g -O2 -c -o xetexdir/libxetex_a-XeTeXFontMgr_Mac.o `test -f 'xetexdir/XeTeXFontMgr_Mac.mm' || echo './'`xetexdir/XeTeXFontMgr_Mac.mm

The other lines show "/usr/bin/clang++" properly being used.

[drkp (Dan Ports)]

Ah, I bet that's the bug I was just looking for that's responsible for #39683...

[ryandesign (Ryan Carsten Schmidt)]

Not sure if it's related.

This one file is being compiled using $OBJCXX which is a variable MacPorts does not set. #38512 requested we set it, but we didn't because its use was so uncommon.

[drkp (Dan Ports)]

Yeah, looks like the failure to set $OBJCXX is causing #39683 and the lack of $OBJCXXFLAGS is breaking universal (#39862).

This is complicated a bit by the fact that texlive's makefiles ignore the $OBJCXX/$OBJCXXFLAGS set at configure time and needs it set in the build environment too, as the portfile already has to deal with for $OBJC/$OBJCFLAGS.

[ryandesign (Ryan Carsten Schmidt)]

Ah I see, so resolving #38512 wouldn't help texlive-bin anyway.

[drkp (Dan Ports)]

Not by itself, but we should do it anyway.

[larryv (Lawrence Velázquez)]

Replying to dports@…:

This is complicated a bit by the fact that texlive's makefiles ignore the $OBJCXX/$OBJCXXFLAGS set at configure time and needs it set in the build environment too, as the portfile already has to deal with for $OBJC/$OBJCFLAGS.

This is how the Portfile currently does it:

pre-build {
    append_list_to_environment_value build "OBJC" ${configure.objc}
    append_list_to_environment_value build "OBJCFLAGS" ${configure.objcflags}
    append_list_to_environment_value build "OBJCFLAGS" ${configure.objc_archflags}
}

Is there any particular reason you can’t do something like this?

build.env-append    OBJC=${configure.objc} \
                    OBJCFLAGS="${configure.objcflags} \
                                [get_canonical_archflags objc]"

[drkp (Dan Ports)]

I was just trying pretty much exactly that. If nothing else, it should definitely be using get_canonical_archflags (that bit of code predates get_canonical_archflags). I don't think it needs to be in a phase anymore, either; that was to get it to run after variants were evaluated back when the +atsui variant was still around.

[drkp (Dan Ports)]

r107956

[cooljeanius (Eric Gallager)]

Cc Me!

[larryv (Lawrence Velázquez)]

I just added configure.objcxx, configure.objcxxflags, and configure.universal_objcxxflags in r107987, so you can switch to those whenever they’re released in stable base.