[Scons-users] pkg-config support

[Russel Winder]

Hi,

Is it my imagination, or s there no support for PKG_CONFIG_PATH when using
ParseConfig and pkg-config.

Is there enthusiasm for making the pkg-config support in SCons distribution a
little bit more usable? I have my own stuff and I recently found

https://github.com/manuelnaranjo/scons-pkg-config

which would seem to imply what is standard currently in SCons isn't yet up to
the job.

[Bill Deegan]

Yes!
Improving pkg-config support would be most welcome!

Post by Russel Winder
Hi,
Is it my imagination, or s there no support for PKG_CONFIG_PATH when using
ParseConfig and pkg-config.
Is there enthusiasm for making the pkg-config support in SCons
distribution a
little bit more usable? I have my own stuff and I recently found
https://github.com/manuelnaranjo/scons-pkg-config
which would seem to imply what is standard currently in SCons isn't yet up to
the job.
--
Russel.
===========================================
Dr Russel Winder t: [phone]
41 Buckmaster Road m: [phone]
London SW11 1EN, UK w: www.russel.org.uk
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

[Russel Winder]

Post by Bill Deegan
Yes!
Improving pkg-config support would be most welcome!

Sounds like that's a yes. :-)

The current system based on using backtick and MergeFlags (which then
uses ParseFlags) of ParseConfig fundamentally assumes all code is
either C or C++. I am not sure this will work for Fortran, but for D
this isn't going to work because mixed D and C code projects cannot use
just one set of environment variables (*). Further, ParseFlags and
MergeFlags are used throughout environment handling – it is not
entirely clear to me just yet that they actually do the right thing for
Fortran and D because ParseFlags is so focussed on C and C++ options.

I am currently thinking that using the ParseConfig route for handling
PkgConfig is possible the wrong way forward. Binding Fortran and D into
the system will end up as a Very Big Task™ and will almost certainly
lead to the real mess of the smart linker stuff. Leaving current stuff
as it is and making a tool seems like the best way forward, even if
later it is decided to merge things in. This militates in favour of
forking Manuel Naranjo's or starting again from scratch with a tool
that works for all languages, not just C, C++, Fortran and D.

I am wondering though, if doing it totally separate is the wrong thing
to do. Perhaps having a "dependency injection" approach is the right
thing to do. Some infrastructure is provided that language tools can
then make use of to provide pkg-config processing capability. This
though mitigates against a standalone tool.

Whilst I am current in a "I can get the final vision" position and
would usually implement something to get started, I am hesitant to as
there are three totally different directions and starting down one
might adversely affect doing the right thing.


(*) Actually this is a belief statement. I assumed the original D tools
used separate environment variables because it was necessary, and
haven't really tested the assumption.

[Bill Deegan]

so does pkg-config spit out D specific flags now?
Perhaps you can paste an example?

Or are you talking about munging pkg-config's output to "do the right
thing" for D compilation (and Fortran)?

-Bill

Post by Russel Winder

Post by Bill Deegan
Yes!
Improving pkg-config support would be most welcome!

Sounds like that's a yes. :-)
The current system based on using backtick and MergeFlags (which then
uses ParseFlags) of ParseConfig fundamentally assumes all code is
either C or C++. I am not sure this will work for Fortran, but for D
this isn't going to work because mixed D and C code projects cannot use
just one set of environment variables (*). Further, ParseFlags and
MergeFlags are used throughout environment handling – it is not
entirely clear to me just yet that they actually do the right thing for
Fortran and D because ParseFlags is so focussed on C and C++ options.
I am currently thinking that using the ParseConfig route for handling
PkgConfig is possible the wrong way forward. Binding Fortran and D into
the system will end up as a Very Big Task™ and will almost certainly
lead to the real mess of the smart linker stuff. Leaving current stuff
as it is and making a tool seems like the best way forward, even if
later it is decided to merge things in. This militates in favour of
forking Manuel Naranjo's or starting again from scratch with a tool
that works for all languages, not just C, C++, Fortran and D.
I am wondering though, if doing it totally separate is the wrong thing
to do. Perhaps having a "dependency injection" approach is the right
thing to do. Some infrastructure is provided that language tools can
then make use of to provide pkg-config processing capability. This
though mitigates against a standalone tool.
Whilst I am current in a "I can get the final vision" position and
would usually implement something to get started, I am hesitant to as
there are three totally different directions and starting down one
might adversely affect doing the right thing.
(*) Actually this is a belief statement. I assumed the original D tools
used separate environment variables because it was necessary, and
haven't really tested the assumption.
--
Russel.
===========================================
Dr Russel Winder t: [phone]
41 Buckmaster Road m: [phone]
London SW11 1EN, UK w: www.russel.org.uk
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

[Russel Winder]

Post by Bill Deegan
so does pkg-config spit out D specific flags now?
Perhaps you can paste an example?

It depends. :-(

Which is part of the problem.

Post by Bill Deegan
Or are you talking about munging pkg-config's output to "do the right
thing" for D compilation (and Fortran)?

Both. :-(

For reasons known only to a certain individual the dmd (and as a knock on
consequence the ldc2) compiler have option structures that are almost, but not
quite, entirely unlike GCC standard options (*). Gdc is fine since it is part
of the GCC suite.

So you have to distinguish dmd/ldc2/ldmd2 on the one hand and gdc/gcc/g++ on
the other, which may necessitate munging options. And some dmd options are
different in ldc2, but not ldmd2.

Moreover the .pc file for a library has options dependent on the compiler
being used to create the library. If you use the same compiler then the
options are right, if you use a different one, you have to munge.

This situation really is a disaster. But one that one must cope with. Either
than or give up, go to a corner, and cry.


(*) With apologies to Douglas Adams for munging his tea from a machine
sentence.

[Bill Deegan]

Is linking binaries build with different D compilers supported? (is the ABI
well defined)

Post by Russel Winder

Post by Bill Deegan
so does pkg-config spit out D specific flags now?
Perhaps you can paste an example?

It depends. :-(
Which is part of the problem.

Post by Bill Deegan
Or are you talking about munging pkg-config's output to "do the right
thing" for D compilation (and Fortran)?

Both. :-(
For reasons known only to a certain individual the dmd (and as a knock on
consequence the ldc2) compiler have option structures that are almost, but not
quite, entirely unlike GCC standard options (*). Gdc is fine since it is part
of the GCC suite.
So you have to distinguish dmd/ldc2/ldmd2 on the one hand and gdc/gcc/g++ on
the other, which may necessitate munging options. And some dmd options are
different in ldc2, but not ldmd2.
Moreover the .pc file for a library has options dependent on the compiler
being used to create the library. If you use the same compiler then the
options are right, if you use a different one, you have to munge.
This situation really is a disaster. But one that one must cope with. Either
than or give up, go to a corner, and cry.
(*) With apologies to Douglas Adams for munging his tea from a machine
sentence.
--
Russel.
===========================================
Dr Russel Winder t: [phone]
41 Buckmaster Road m: [phone]
London SW11 1EN, UK w: www.russel.org.uk
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

[Russel Winder]

Post by Bill Deegan
Is linking binaries build with different D compilers supported? (is the ABI
well defined)

I haven't had any trouble but


Debian only supports ldc2 so everything gets compiled with it, and yet, it si
just the one platform, and you still can't trust the .pc files. Trust me on
this. :-)

D is very much in the Rust model: You download the source of packages from the
central repository and compile then for the project – except that there are
some issues that Cargo/Rust has solved but Dub/D has not entirely solved. This
actually militates massively in favour of ignoring pkg-config and getting on
with getting the Dub builder working properly. Indeed Meson now has this
sorted – a push to get it working properly for SCons, but it is just a tool,
not integrated with the SCons core.

On the other hand, Debian at least, not sure about others, do compile
libraries as packages and so there is the facility to use pkg-config, so it
ought to be made to work properly. It isn't good enough to rely on
ParseConfig, because that function is completely C and C++ focused.

[Russel Winder]

Hi,

Just to "keep this idea warm" I should report that I am tinkering with
pgkconfig support in SCons that is harmonious with the needs of D. C
and C++ are easy in comparison so get dealt with easily.

If anyone else is at all interested in this, it would be good to chat
over previous work by others and what I have been doing, as I am
worried I am getting into an ideas tunnel and not seeing good
alternatives.

cf. https://github.com/russel/SCons_PkgConfig