SM> Instead, I see a potentially different approach. Write an scons
SM> build file (typically named SConstruct) and deliver that in the
SM> Modules directory.
Jeremy> I don't care much about the Modules directory actually. I want
Jeremy> this for third-party extensions that use distutils for
Jeremy> distribution, particularly for my own third-party extensions
Jeremy> :-).
As I think has been hashed out here recently, there are two functions that
need to be addressed. Distribution/installation of modules is fine with
distutils as it currently sits.
Jeremy> It sounds like you're proposing to drop distutils in favor of
Jeremy> SCons, but not saying so explicitly. Is that right?
No. Here, I'll put it in writing: I am explicitly not suggesting that
distutils be dropped.
I suggested that a SConstruct file be added to the modules directory to be
used by people who need to do more than install modules. That's it.
Jeremy> If so, we'd need to strong case for dumping distutils than
Jeremy> automatic dependency tracking. If that isn't right, I don't
Jeremy> understand how SCons and distutils meet in the middle. Would
Jeremy> extension writers need to learn distutils and SCons?
No. I'm only suggesting that a SConstruct file be added to the Modules
directory. I don't want it tied into the build process, at least for the
time being. As Guido indicated, scons is still in its infancy.
Skip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4